Crunchez vos adresses URL
|
Rejoignez notre discord
|
Hébergez vos photos
Page 32 sur 38 PremièrePremière ... 22242526272829303132333435363738 DernièreDernière
Affichage des résultats 931 à 960 sur 1125
  1. #931
    On peut effectivement ne sauvegarder qu’après l’atteinte d’un point précis qui pose une situation n’héritant pas des actions du joueur ou si peu.

    Mais combien de temps aujourd hui un joueur est prêt à passer devant son écran sans sauvegarder ? Et aller jusqu’au bout d’un temps X et devoir tout se retaper s’il échoue ? 10 min / 20 min ? Ou plus ?
    Ca existe ce genre de métrique ?

  2. #932
    Tout dépend de ta cible. Les joueurs de rogue like sont prêts à ça par exemple. Les joueurs mobile hypercasu non.

  3. #933
    Il y a pas mal de jeux de combat au tour par tour où tu ne peux pas sauver au milieu d'un combat.
    Après, il y a des jeux à base de points de sauvegarde (e.g. Metroidvania-like) mais c'est sûr qu'en général, c'est pas vendeur.

  4. #934
    Citation Envoyé par SalsifiNoir Voir le message
    On peut effectivement ne sauvegarder qu’après l’atteinte d’un point précis qui pose une situation n’héritant pas des actions du joueur ou si peu.

    Mais combien de temps aujourd hui un joueur est prêt à passer devant son écran sans sauvegarder ? Et aller jusqu’au bout d’un temps X et devoir tout se retaper s’il échoue ? 10 min / 20 min ? Ou plus ?
    Ca existe ce genre de métrique ?
    J'ai contourné le problème en forçant la sauvegarde dès que le joueur quitte le jeu, ou charge une zone, ou ferme un placard.

    Du coup, j'ai également joué avec la notion de "mort". Un peu à la manière de Outward. D'un point de vue personnel, je me dis que même sur un jeu solo, l'ironman c'est bien, mais j'aime pas "perdre" définitivement. Donc j'essaye de trouver un entre deux.

    Ca dépend des jeux hein, et je voulais explorer là dessus.

  5. #935
    Y'a 2-3 jeux indé récemment qui m'ont remotivé à faire des petits jeux amateur

    J'avais une problématique à l'époque, c'était comment gérer le partage de données entre plusieurs entités/gameobjects dans une même session.

    J'utilisais des ScriptableObject, et c'était assez ambigu car j'en créais également pour leur objectif premier : persister de la configuration/données plutôt que de les harcoder.
    Donc je pouvais avoir un SO qui pouvait avoir les deux : par exemple "baseHeroHP" qui lui était figé (et n'était voué à être modifié qu'en mode édition Unity), et un "currentHeroHP" qui lui était changeant en mode exécution (mais à chaque fois reset lors qu'une nouvelle exécution).

    Vous avez d'autres techniques ?

  6. #936
    Tu crée un singleton nommé GlobalManagerVariables ou un truc du genre et tu y fous tes variables. Il sera persistant à travers toutes tes scènes vu qu'il est DontDestroyOnLoad.
    Tu utilises tes ScriptableObjects pour effectivement des trucs du genre baseHeroHP et si tu en as vraiment plein tu peux les faire correspondre à une BDD, ce qui centralise les données et les rends bien plus faciles à suivre et modifier.

  7. #937
    Citation Envoyé par Harsyx Voir le message
    Y'a 2-3 jeux indé récemment qui m'ont remotivé à faire des petits jeux amateur

    J'avais une problématique à l'époque, c'était comment gérer le partage de données entre plusieurs entités/gameobjects dans une même session.

    J'utilisais des ScriptableObject, et c'était assez ambigu car j'en créais également pour leur objectif premier : persister de la configuration/données plutôt que de les harcoder.
    Donc je pouvais avoir un SO qui pouvait avoir les deux : par exemple "baseHeroHP" qui lui était figé (et n'était voué à être modifié qu'en mode édition Unity), et un "currentHeroHP" qui lui était changeant en mode exécution (mais à chaque fois reset lors qu'une nouvelle exécution).

    Vous avez d'autres techniques ?
    Je ne vois pas le problème de mettre des données statiques et dynamiques dans un même Scriptable Object, c'est exactement ce que je fais pour le jeu que je développe actuellement. Pour exemple, voilà le script d'un SO qui stocke les HP de mon Player (c'est juste un int) :

    Code:
    using UnityEngine;
    
    [System.Serializable]
    [CreateAssetMenu(menuName = "ScriptableObjects/RangedInt")]
    public class RangedInt : ScriptableObject
    {
        [SerializeField] private int _value;
        [SerializeField] private int _defaultValue;
        [SerializeField] private int _minValue;
        [SerializeField] private int _maxValue;
    
        #region Public properties
    
        public int Value
        {
            get => _value;
            set => _value = Mathf.Clamp(value, _minValue, _maxValue);
        }
    
        public int DefaultValue
        {
            get => _defaultValue;
        }
    
        public int MinValue
        {
            get => _minValue;
        }
    
        public int MaxValue
        {
            get => _maxValue;
        }
    
        public float Normalized
        {
            get => _value / (float)_maxValue;
        }
    
        #endregion
    
        #region Public Methods
    
        public void AddToValue(int value)
        {
            Value += value;
        }
    
        public void SusbstractToValue(int value)
        {
            Value -= value;
        }
    
        #endregion
    }
    T'as les "defaultValue", "minValue" et "maxValue" qui ne bougent pas et seule "Value" change selon ce qui se passe dans le jeu.
    Dernière modification par yodaxy ; 12/02/2023 à 14h46.

  8. #938
    Citation Envoyé par Grosnours Voir le message
    Tu crée un singleton nommé GlobalManagerVariables ou un truc du genre et tu y fous tes variables. Il sera persistant à travers toutes tes scènes vu qu'il est DontDestroyOnLoad.
    Ca me parait vraiment ultra crados
    Enfin ça peut faire une sacrée floppée de variables dans un seul gameobject, et j'aime bien le fait d'encapsuler certaines valeurs et d'être certains que d'autres scripts ne pourront pas y accéder/toucher.

    Citation Envoyé par yodaxy Voir le message
    Je ne vois pas le problème de mettre des données statiques et dynamiques dans un même Scriptable Object, c'est exactement ce que je fais pour le jeu que je développe actuellement. Pour exemple, voilà le script d'un SO qui stocke les HP de mon Player (c'est juste un int) :

    T'as les "defaultValue" et "minValue" qui ne bougent pas et seule "Value" change selon ce qui se passe dans le jeu.
    Ouep c'était exactement ça que je faisais.

    Je m'étais pris la tête "à l'époque" car y'avait aucune ressource/tutoriel/whatever qui en parlait, et en effet ça finissait souvent dans un GameObject DontDestroyOnLoad.
    J'avais l'impression de bidouiller un truc bancal avec les SO, et qu'à un moment donné ma donnée pourrait être altérée en cours d'exec.

    Notamment du fait que si je me trompe pas (?) les SO sont aussi reset/désalloué à chaque changement de scène, sauf s'ils sont au moins référencés une fois. Donc j'avais un peu une arborescence très hiérarchisée de mes game/scriptable objects dans les scènes, et peur de me louper à un endroit, d'avoir une désynchro de données qui pouvait être assez complexe à debug.

    Merci pour vos réponses, je vais repartir là dessus alors

    Je me prends toujours beaucoup trop la tête sur l'aspect architecture/perfs au détriment du gameplay

  9. #939
    Citation Envoyé par Harsyx Voir le message
    Notamment du fait que si je me trompe pas (?) les SO sont aussi reset/désalloué à chaque changement de scène, sauf s'ils sont au moins référencés une fois. Donc j'avais un peu une arborescence très hiérarchisée de mes game/scriptable objects dans les scènes, et peur de me louper à un endroit, d'avoir une désynchro de données qui pouvait être assez complexe à debug.
    D'après mon expérience je ne crois pas que les SO soient reset au changement de scène (sauf si tu le fait toi-même évidemment), c'est l'avantage de garder la valeur dans un asset : elle reste toujours immuable quel que soit la progression dans le jeu. Seul quitter le jeu et le relancer reset les valeurs d'un SO je crois.

  10. #940
    Citation Envoyé par Harsyx Voir le message
    Ca me parait vraiment ultra crados
    Bof, le propre de l'un est le sale de l'autre.
    C'est bien pour cela que je ne mets pas le nez en profondeur dans ce que font mes employés et les laisse écrire comme ils l'entendent tant que c'est:
    1) lisible
    2) documenté
    3) suffisamment performant
    4) scalable
    et bien sur que cela fonctionne.

  11. #941
    De mon coté, j'avais lu pas mal sur les ScriptableObject et après avoir joué avec, j'ai tout mis à la poubelle et je suis parti sur un singleton qui référence les classes dont j'ai besoin ou, plus exactement, provoque le chargement de ce qui est persistant.
    Oui, on peut reprocher plein de trucs aux singletons, mais pour passer d'une scène à une autre, c'est le mieux à mon avis.
    Les DontDestroyOnLoad, ça doit valoir le coût quand tu persistes d'un niveau similaire à un autre. Dans mon cas, j'ai juste pas besoin des mêmes données dans les différentes scènes (e.g. le modèle 3D ne sert qu'en combat, pas sur la carte du monde - même si éventuellement je pourrais m'en servir un jour dans l'inventaire)
    Après, j'ai pas forcément tout compris sur les SO, mais si je fais 2 parties, je ne veux pas avoir les SO de la partie 1 dans la partie 2 et inversement. En gros, les constantes dans des SO, oui, les variables non. Si tu charges ton niveau, que tu reviens au screen de début de partie et que tu redémarres, en implémentant ça avec 2 scènes (loading screen + jeu), les modifications que tu as faites dans les SO de la première partie, tu les veux pas dans la deuxième.

  12. #942
    Je viens de tester dans un projet vierge sur la dernière LTS, les SO passent bien dans le garbage collector quand il y a changement de scène et qu'ils ne sont pas référencés dans la nouvelle (et qu'on revient sur la précédente).
    Ce qui parait logique dans le cadre d'asset (qui sont retirés de la ram).

    Citation Envoyé par LDiCesare Voir le message
    En gros, les constantes dans des SO, oui, les variables non. Si tu charges ton niveau, que tu reviens au screen de début de partie et que tu redémarres, en implémentant ça avec 2 scènes (loading screen + jeu), les modifications que tu as faites dans les SO de la première partie, tu les veux pas dans la deuxième.
    Je pense que dans tous les cas, tu es obligé d'implémenter une initialisation des variables de ton SO puisqu'en mode édition sur Unity, les valeurs modifiées en runtime sont gardées a posteriori.
    Sinon ça t'obligerait à la fin de chaque test dans l'éditeur de remettre la valeur par défaut des variables de ton SO

  13. #943
    Citation Envoyé par Harsyx Voir le message
    Je viens de tester dans un projet vierge sur la dernière LTS, les SO passent bien dans le garbage collector quand il y a changement de scène et qu'ils ne sont pas référencés dans la nouvelle (et qu'on revient sur la précédente).
    Ce qui parait logique dans le cadre d'asset (qui sont retirés de la ram).
    Ok c'est bon à savoir. Mais du coup les valeurs du SO sont reset alors ?

  14. #944
    Citation Envoyé par yodaxy Voir le message
    Ok c'est bon à savoir. Mais du coup les valeurs du SO sont reset alors ?
    Je confirme que si le GC passe et que le SO n'est pas référencé dans la nouvelle scène, ses valeurs sont reset.

    Dans l'editor c'est un peu plus tricky car dans le cadre de mon test, même si le SO n'est pas référencé MAIS que je l'ai d'affiché dans l'inspector, alors le GC ne le libère pas et de fait, il n'est pas reset.

    Et à noter que le GC n'a pas l'air de passer systématiquement lors d'un changement de scène (ce que je croyais - à tort), donc il se peut que dans certains cas, le SO reste en mémoire et garde donc ses valeurs.


  15. #945
    Okay ouais c'est louche

    Faudra que je garde ça en tête si je ne référence pas mon SO dans une scène (même si je doute que ce cas de figure m'arrive).

  16. #946
    Bon finalement je fais simple en sauvegarde : je valide juste l’étape de passage d’une scène à l’autre et puis après je garde à la fin les quantités et les types de gameobjects que le joueur et la position de ceux qui sont statiques si on revient à l’endroit.

    Ca évite de gérer tout le reste et je fais court dans les étapes comme ça c’est plus dynamique.
    Et pas lourdingue si on doit recommencer.
    D’ailleurs je vais rajouter un timer sur chaque scène pour faire un petit challenge, ça donne envie de recommencer pour avoir un meilleur temps.
    J’adapte un peu le principe des séquences pour éviter d’avoir un truc trop lourd.

  17. #947
    Hello

    Est-ce que vous avez déjà installé Unity sur un serveur, ou est-ce qu’il est possible de l’utiliser en version portable ? Ce serait pour l’utiliser en milieu scolaire, dans le cadre d’un club JV.

  18. #948
    T'as une méthode dans la doc pour l'installer sans Unity Hub: https://docs.unity3d.com/Manual/Depl...tyOffline.html
    A la fac quand on doit l'installer dans un labo on installe Hub sur toutes les machines et on consacre une séance au fait de le télécharger, la licence et tout l'environnement Hub en général.

  19. #949
    Merci pour le lien et le retour !

    Effectivement, sans hub ça sera certainement moins lourd en termes de téléchargements multiples, comme on doit le faire pour x machines si on ne peut pas l’installer sur le serveur.

  20. #950
    Ca y est je me suis décidé sur un prototype à faire, je pars sur un mix Fire Emblem/Tactics Ogre/Pokémon. (oui rien que ça comme on dit, plus on est nul plus on est ambitieux et moins ça dure longtemps )

    En pixel art (comme ça je pourrais utiliser des ressources gratuites/open source pas forcément de bonne qualité et les grossir au max ).

    Bref j'ai galéré toute la soirée parce que j'avais un vieux bleeding d'1px lors de certains déplacements de caméra, si jamais ça ne snap pas pile poil sur un pixel alors ça va chercher le px d'à côté sur la texture, et forcément sur mon tileset tout était collé...
    Petit tour sur photoshop pour mettre des bordures invisibles autour des tiles, et les balancer dans un atlas après.
    Avec en bonus mon projet unity que j'avais mis en 2D URP pour me la jouer, mais forcément sur la LTS y'a pas la pixel perfect camera pour URP

  21. #951

  22. #952
    Oui mais que sur la 2022.X non ? En tout cas sur la dernière LTS j'ai pas trouvé où était le composant.

  23. #953

  24. #954
    Baaaah c'est très bizarre.
    J'ai recréé un nouveau projet en 2D URP (sur la 2021) et en effet y'a le bon composant pixel perfect qui fonctionne correctement.
    Pourtant j'avais fais la même manip' ce week-end et au moment d'ajouter le composant, ça me disait qu'il était incompatible.
    Et j'avais été conforté dans cette direction avec cette personne d'Unity qui confirme que le pixel perfect URP est dispo' que pour 2022 : https://forum.unity.com/threads/help...derer.1337825/


    Je vais rester sur le built-in je suppose que ça fera aucune diff de toute manière

  25. #955
    Je saurais pas trop si je conseille de rester sur le built-in pour un nouveau projet en 2023 quand même. URP a pas mal de choses maintenant, et c'est ça qu'ils maintiennent le built-in devient plus obsolète chaque jour.
    Enfin c'est juste mon avis de quelqu'un qui utilise pas Unity pour de la production (sauf sur mobile, et là je suis sur URP). Je serais curieux de voir d'autres avis.

    EDIT: Non rien j'ai mal lu, tu parlais juste du package en fait. Cela dit, je reste curieux des avis sur le rendering URP/Built-in.
    Je pense que tu as raison du coup pour le package pixel perfect spécifique URP. Peut-être que si tu veux utiliser du camera stacking (par exemple) avec pixel perfect tu pourras pas du coup puisque c'est une feature URP. Bonne chance

  26. #956
    Ah effectivement, URP 14 n'est pas dispo sous 2021.
    Ce qui est bizarre dans cette histoire c'est que le pixel perfect 2D que tu viens de recréer fonctionne en URP alors qu'il est pour le built-in.

    Si tu n'as pas besoin directement d'une des fonctionnalités de l'URP tu peux rester en built-in mais comme l'indique bien schouffy, il est vraiment plutôt en fin de vie qu'autre chose. Perso cela fait quelques années déjà qu'on est passé sans regret à l'URP.

  27. #957
    Je suis sur la 2021.3.20 et là avec l'URP j'ai bien la Pixel Perfect Camera qui fonctionne correctement... (et l'URP est en 12.1.10)



    Vous me conseilleriez de passer sur la 2022 dans ce cas ?
    (parce qu'en soit oui, j'ai pas besoin de prendre une version ultra stable pour un petit prototype perso)

    A titre personnel, tant que ça fonctionne correctement sur Android et sur PC, et que ça crash pas trop souvent, ça me va

  28. #958
    C'est un projet perso, donc plutôt oui.
    Cela fonctionne pour l'instant mais cela peut planter si ce n'est pas fait pour donc plutôt oui.
    Tu n'as pas vraiment besoin des fonctionnalités de 2022 par rapport à la LTS 2021, donc plutôt non.
    A toi de choisir.

  29. #959
    Helloo

    Une question de débutant : est-ce qu’il est possible de récupérer un package précis d’asset (qui a été downloadé dans le Package Manager) dans l’explorateur de fichiers Windows, afin de l’installer sur l’instance Unity d’un autre PC ?

    En l’occurrence, là je cherche à récupérer le « 3D Game Kit ». Je ne vois vraiment pas où il est dans Windows (pourtant il fait 2,16 Go, donc ça ne devrait pas passer inaperçu).
    Dernière modification par honu ; 13/03/2023 à 06h39.

  30. #960
    Oui.
    La première chose que je fais sur toutes mes installations Unity est toujours de créer un lien symbolique vers où ce répertoire est placé vers ailleurs sur un autre disque histoire de pouvoir contrôler finement tout cela.
    Le répertoire que tu cherches se trouve dans "C:\Users\accountName\AppData\Roaming\Unity\As set Store" et s'appelle "Asset Store-5.x" et contient un sous-répertoire par auteur d'asset que tu utilises.

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
  •