Créer son jeu avec Unity3D !

[LDiCesare]

Parce que je ne connais pas l'option.
Tu fais ça comment?

Edit: Apparemment cocher Development build permet d'avoir une console.
Par contre c'est tellement petit que c'est illisible. Un fichier serait tellement mieux...

Re-edit: Y a un bouton open log file (pareil, c'est tout petit et illisible) donc ça devrait être déboguable maintenant.
Merci de m'avoir poussé dans la bonne direction.

[SalsifiNoir]

Quelqu'un sait pourquoi on a des trucs complètement différents quand on lance dans l'éditeur et qu'on fait un build?
Du genre tous mes sprites sont corrompus (mélange de sprites, inversion, genre les adresses dans l'atlas sont pas bonnes).
Accessoirement j'ai aussi des gameobjects qui ne se comportent pas pareil, etc.
Je croyais qu'il y avait un output.txt ou similaire dans le répertoire _Data du build mais non. Je n'arrive pas à voir comment forcer la création du fichier de log ou alors je ne cherche pas au bon endroit?

Si tu as ce phénomène c’est que tu n’as pas codé correctement les awake, start, voir la création d’une fonction init() qui affecte ce qu’il faut au bon moment avant l’usage de tes objets là où il le faut effectivement.

Tu n’as réellement le même comportement entre l’éditeur et le build que lorsque c’est codé dans les règles de l’art.

As-tu mis en place dans l’éditeur un debug.log qui print à chaque étape de ton chargement pour vérifier que l’ordre d’initialisation de ta scène correspond bien à ce que tu souhaites techniquement ?

[Grosnours]

Tu n’as réellement le même comportement entre l’éditeur et le build que lorsque c’est codé dans les règles de l’art.

Oui, voilà.
Tu as des trucs qui sont spécifiquement uniquement dans l'éditeur (et c'est clairement codé/indiqué ainsi) mais grosso modo si tu vois des différences notables entre ta scène dans l'éditeur et une fois compilée c'est qu'il y a une couille dans le potage dans ton code quelque part plus qu'un problème latent de la part d'Unity.

[LDiCesare]

En fait j'avais plusieurs problèmes.
Un Start au lieu d'un Awake qui faisait que la transition de scène fonctionnait dans l'éditeur mais pas dans le build. En fait, la scène d'arrivée ne fonctionnait plus non plus dans l'éditeur si on la lançait directement.
L'utilisation du sprite atlas: L'éditeur s'en fout complètement, donc si on ne met pas les bonnes options dans l'atlas (dans mon cas interdire la rotation entre autres), on ne le voit qu'après un build.
Enfin j'avais un appel sur OnValidate() et là c'est moi qui suis juste débile, vu que c'est un appel fait pour mettre à jour mon inventaire quand je le modifie via l'éditeur, donc forcément si je fais pas un appel équivalent dans Awake() ou autre, en build ça marche pas.

J'avais surtout pas anticipé le coup de l'atlas. Pour le reste, effectivement, je sens que je vais devoir me taper des traces d'initialisation pour m'assurer que tout se passe dans le bon ordre. En tous cas, je suis content d'avoir fait un vrai build relativement tôt dans mon dev, ça m'aura évité de me prendre une tonne de problèmes d'un coup le jour où j'essaierai de mettre tout ensemble.

[Cmos]

Coinjour,

voilà peu de temps que je bidouille Unity (en 3D seulement, et c'est génial!) et je profite de ma découverte de ce sous-forum pour vous poser une question en bon françois parce que je bute sur un truc qui me prend la tête. (Je suppose qu'il vaut mieux poster dans ce fil plutôt que d'en créer un nouveau)

Le contexte :

Spoiler Alert!

Pour poser le contexte, je faits des essais divers autour d'un projet basique de TPS tel qu'on pouvait en voir tout début 2000.
je me suis attelé à la mise en place du système régissant les interactions entre le joueur et le groupe d'objets utilisables. L'idée c'est que quand on trouve un de ces objets, on peut choisir quoi en faire/ne rien faire via un menu dédié. Donc je m'approche de l'objet, le menu surgit, je choisi quoi faire et... et c'est là que je me gratte la tête pour dire "vas y objet déroule ton code":

> Ma première idée était de positionner une variable publique dans le script du joueur selon l'action choisie à travers le menu surgissant et d'autre part, dans le script de l'objet, lire cette variable et agir selon la valeur (en gros 0=rien faire, 1=faire action1; 2=faire action alternative). Mais j'ai revu ma copie de peur de vite finir en mode spaghetti code avec des variables de partout.

> Ensuite je suis parti sur des unityevents pour transmettre les ordres. C'est plus propre, plus limpide, on regarde l'inspecteur et on sait déjà qui affecte quoi. Mais voilà, c'était trop beau. Les unityevents ne permettent pas d'aller chercher une info. Juste de déclarer à qui veut l'entendre... un événement. En gros ça fait ce que c'est sensé faire et ça fonctionne pour 90% des cas (ici, ouvrir/fermer une porte, faire péter du C4, switcher un appareil, en gros tout ce qui marche sans feedback entre objet et joueur).

> Finalement je me suis dit que je pourrait envoyer les infos nécessaire si besoin à l'objet via unityevent en même temps que je demande à l'objet d'agir, en le passant en paramètre. Soit techniquement AVANT que l'objet n'en ai besoin et ça me paraît pas super logique et ça m'embrouille un peu.

Donc retour case départ avec la lecture d'une variable publique...

PS: en plus j'arrive pas à me contenter d'une solution que je considère bancale même si c'est temporaire en attendant de trouver mieux du coup j'avance pas ^^

Ma question est simple : Quelle est la méthode d'échange d'infos entre scripts de GameObject séparés de manière propre et rigoureuse sans finir en plat de spaghetti ? Quel est l'état de l'art à ce sujet (j'imagine que balancer des var publique de partout n'en fait pas partie, si)?

[yodaxy]

Y a pas mal de méthodes mais je pense que tu peux continuer d'utiliser les UnityEvents et complémenter avec des Scriptable Objects, qui permettent à la fois d'être ajouté dans l'inspecteur (et donc dans un event) et de stocker des valeurs diverses dans des assets, du coup pour envoyer des infos vers un autre script c'est nickel.

Une bonne vidéo à leur sujet :



Sinon dans les interactions physiques (OntriggerEnter / OncollisionEnter) tu peux récupérer tout un tas d'infos sur n'importe quel objet avec lequel ton Player entre en contact, ou exécuter des méthodes dans celui-ci. En général dans ces méthodes tu peux faire un "GetComponent<ClassAvecLaquelleJeVeuxInterragir>() .MethodeQueJeVeuxLancer" sur l'objet en collision.

[DarwinMorkai]

Coin !
Je ne sais pas si ca va répondre a ta question, mais dans cette vidéo, il a l'air d'expliquer ce que tu cherches, mais je crois en passant pas une variable comme tu le dis, mais il donne plusieurs astuces
https://www.youtube.com/watch?v=yLLRO7KqnX4


J'espère que ça t'aidera !

[Grosnours]

Les scriptables objects c'est très bien, mangez-en.
Maintenant si tu veux définir des variables ou constantes qui seront disponibles pour tous les GameObjects dans toutes les scènes, une méthode classique est de faire appel à un singleton don't destroy on load qui contiendra toutes ces variables.

[Cmos]

Je ne connaissait pas les scriptable objects. Je vois que dans mon cas l'intérêt serait d'utiliser ça en tant qu'intermédiaire entre les différents scripts. A creuser c'est encore très flou.
Le singleton oui mais s'il ne peut y en avoir qu'un mieux vaut réserver ça à la gestion globale du jeu, j'imagine.

Merci pour vos suggestions en tout cas.

[yodaxy]

Le singleton oui mais s'il ne peut y en avoir qu'un mieux vaut réserver ça à la gestion globale du jeu, j'imagine.

Tu peux totalement avoir plusieurs Singletons, mais il faut juste qu'il n'y ait qu'une seule instance de la même classe (sinon ça s'appelle un Multiton).
Tu peux avoir un Singleton GameManager, un LevelManager, un ItemManager, etc.

Bon après perso je dirais qu'il il faut éviter d'en faire trop parce que ça peut vite devenir le bordel

[schouffy]

J'ai réfléchi vite fait et à priori je partirais comme ça :

Un MonoBehaviour avec :
- OnTriggerEnter et OnTriggerExit pour pop in/out ton menu d'actions
- Un array d'objets name/UnityEvent pour que tu puisses ajouter tes items directement via l'inspecteur

Sur un autre MonoBehaviour tu crées l'implémentation de chacune de tes actions, et tu le met sur le même game object. En fonction de tes actions, tu peux sans doute réutiliser des MonoBehaviour génériques. Par exemple "ramasser" ça peut être une action générique que tu met sur plusieurs GameObjects différents. Raccorde les UnityEvents dont je parle plus haut à chaque implémentation.

Quand tu entres dans ta zone trigger, affiche le menu avec les actions. Quand tu sélectionnes une action, execute le UnityEvent associé.

[Cmos]

Tu peux totalement avoir plusieurs Singletons, mais il faut juste qu'il n'y ait qu'une seule instance de la même classe (sinon ça s'appelle un Multiton).
Tu peux avoir un Singleton GameManager, un LevelManager, un ItemManager, etc.

Bon après perso je dirais qu'il il faut éviter d'en faire trop parce que ça peut vite devenir le bordel

Ah ben c'est bon à savoir ça merci!


Bon en fait mon histoire d'unity event est foireux puisqu'en fait ça m'oblige à drag/drop chaque item... Je sais pas pourquoi je m'étais mis en tête que je n'avais qu'à drag/drop un prefab pour que ça s'applique à tous du même type...
Mais bon là j'arrête pour le moment je peut pas me concentrer (migraine).

edit:

J'ai réfléchi vite fait et à priori je partirais comme ça :

Un MonoBehaviour avec :
- OnTriggerEnter et OnTriggerExit pour pop in/out ton menu d'actions
- Un array d'objets name/UnityEvent pour que tu puisses ajouter tes items directement via l'inspecteur

Sur un autre MonoBehaviour tu crées l'implémentation de chacune de tes actions, et tu le met sur le même game object. En fonction de tes actions, tu peux sans doute réutiliser des MonoBehaviour génériques. Par exemple "ramasser" ça peut être une action générique que tu met sur plusieurs GameObjects différents. Raccorde les UnityEvents dont je parle plus haut à chaque implémentation.

Quand tu entres dans ta zone trigger, affiche le menu avec les actions. Quand tu sélectionnes une action, execute le UnityEvent associé.

Merci je prends note, je verrai ça à tête reposé

[SalsifiNoir]

Je viens de passer à la toute dernière version officielle la 2022.2 et ils ont basculé le système de navigation au dernier jus de ce qui était sous github.

Ca marche presque bien en conversion mais il y a une évolution avec les nav mesh obstacles.

Avant le trou dans le nav mesh se limitait au bord de l’obstacle défini par la box verte.
Maintenant il y a en plus une box blanche avec une sorte de tolérance encore plus loin.

Ce qui fait que tous les ajustements précédents ne sont plus atteignables car le trou dans le nav mesh est bien plus grand.

Savez vous où on peut ajuster cette box de tolérance sans changer la box d’obstacle initiale ?
J’ai rien trouvé sur ça.

[Grosnours]

Désolé, aucune idée vu que j'essaie de me limiter aux LTS.
Mais j'ai une question pour toi vu que tu as le goût du risque: tu as toujours sur 2022 les horribles temps d'attente de 2021 dès que tu fais un truc du genre changement de scène avec les boite de messages "Hold On" ou ils ont corrigé cela ?

[schouffy]

C'est pas juste qu'ils ont pris en compte l'agent radius dans le navmesh obstacle ?

[SalsifiNoir]

C'est pas juste qu'ils ont pris en compte l'agent radius dans le navmesh obstacle ?

C'est effectivement ça, après avoir fait quelques tests sur cette idée.
C'est moche car c'est plus compliqué qu'avant car il faut jouer avec le radius qu'on peut ignorer pour espérer avoir un objet passer ou atteindre un bon endroit.
Donc impossible de valider sans lancer et tester ingame alors que sur un prefab on posait l'obstacle et on savait que c'était bon.
Pas un progrès...

- - - Mise à jour - - -

Désolé, aucune idée vu que j'essaie de me limiter aux LTS.
Mais j'ai une question pour toi vu que tu as le goût du risque: tu as toujours sur 2022 les horribles temps d'attente de 2021 dès que tu fais un truc du genre changement de scène avec les boite de messages "Hold On" ou ils ont corrigé cela ?

Pour le moment, pas vu cet effet, mais mon projet est très petit.

[LDiCesare]

Ca me parait normal de rajouter le rayon de ton objet quand tu fais tes navmeshes. Surtout si le même jeu d'obstacles peut servir à des mobiles de tailles différentes.

[SalsifiNoir]

Oui mais on le visualise pas dans un prefab, donc impossible de caler les points d’accès à un drop par exemple précisément ou alors ils ont introduit un truc pas encore vu.

Par contre dans la 2022 ils ont ajouté les spherecast, boxcast etc… asynchrones et c’est super pour les perfos.

[SalsifiNoir]

Question bête : en quoi la taille des objets influence sur les perfos en dehors du nombre de noeuds d’un mesh ?
Y’a une conversion d’unité à l’import vers unity, mais si je fais une scène avec une taille de 10 de 100 ou de 1000 les objets sont plus gros mais est ce que cela change les performances ? Du genre une sphère cast est forcement plus grande en rayon de même sur l’overlaps de la sphère.
Donc distance plus grande du rayon donc volume plus grand. C’est bien dit que le raycast par exemple est sensible à la distance mais de l’échelle globale ou de la distance réelle ?
On prend un asset de caillou, ça fait quasiment une montagne sur une tuile de terrain par défaut.
On prend un autre asset d’arbre, on dirait un cure dent au milieu de la même tuile…

Y’a une règle qui dit quelle dimension de scène est optimale ?

[Grosnours]

Les dimensions n'ont aucune importance si tous tes assets ont exactement la même échelle.
Il m'arrive souvent d'avoir des assets de tailles totalement différentes et je dois passer par une étape de mise à l'échelle dans leur préfab. Mais la taille de leur modèle, je m'en tape. L'interface de déplacement de Blender (et dans une moindre mesure Unity auss) est un poil plus facile à utiliser avec des modèles plus grands, donc il ne vaut mieux pas faire dans le liliputien non plus.

Après si tu as des invariants genre terrains, là par contre l'augmentation démesurée de leur taille n'est pas gratuite en terme de perf. Cela guidera donc tes choix d'échelles.

Perso je me préfère toujours avoir une tuile de grid qui correspond à une de mes unités de base (maison ou perso, ou ce qui est l'unité de base du jeu en question).

Question bête : en quoi la taille des objets influence sur les perfos en dehors du nombre de noeuds d’un mesh ?

Là par contre je n'ai pas bien compris ce que tu veux dire.

[SalsifiNoir]

Oui ma phrase était pas claire mais en l’état j’ai quand même une réponse explicite
Je voulais surtout parler de l’augmentation de taille d’un objet sans augmenter le nombre d’éléments dans le maillage.

[Grosnours]

Points/arrêtes/faces (vertex/edge/face) sont les mots que tu cherchais alors.

Ceci dit il est très important d'avoir les modèles en différentes versions si tu utilises le concept de LOD. Car tu assigneras dans le LOD Group un tel modèle à une telle distance de vue, ce qui te permet de d'adapter dynamiquement le nombre de triangles à l'écran.

D'ailleurs c'est un de mes soucis en ce moment, acheter des modèles et les personnaliser c'est très bien mais je suis obligé de me taper à la pogne (quand les algos de ruines de mesh sont à la tue, càd souvent) la ruine de mes meshs pour les points de vue plus éloignés. Ce qui n'est pas trivial et peut prendre beaucoup de temps, surtout si tu veux offrir des transitions entre modèles les meilleures possibles.
Alors que si tu avais développé (ou fait développer) le modèle toi-même, tu aurais déjà différents modèles avec différents niveaux de détails naturellement, car le process de design part habituellement d'une version plus sobre/sommaire pour ensuite évoluer dans les détails (et donc le nombre de triangles).

[SalsifiNoir]

Parlons un peu save and load.

Qu’est ce qu’on peut mettre en place comme technique de sauvegarde et de rechargement qui soit pas trop compliqué ?

Je pensais sauvegarder les positions des gameobjects, leur orientation, et les quelques variables visibles du joueur.
Mais dans quel format pour que ce soit performant mais pas accessible donc pas de playerprefs.

Autre précision, rien n’était pensé pour faire de la sauvegarde au début donc c’est peut être pas bien question méthode ? Faut intégrer ça dès le début ?

[Grosnours]

Tu sauves ce qui est pertinent dans ton jeu, ce qui peut varier énormément. Et donc dans un format que tu définis toi-même.
Dans l'idéal, il vaut mieux streamer des données aussi petites que possibles, donc utiliser de la compression est peut être une bonne idée.
Tu peux sauvegarder localement ou en ligne, au choix, en clair ou en crypté au choix.

A moins que tu aies un modèle client/serveur (auquel cas cela pourrait avoir une incidence sur le schéma de base de données), la sauvegarde est quelque chose sur lequel tu peux travailler un peu plus tard dans ton projet sans trop de souci.

[LDiCesare]

Qu'est-ce que tu veux dire par "pas accessible"?
En termes de format, ça dépend vraiment de ce que tu veux faire. Tu peux par exemple facilement sérialiser en json, mais je trouve ça gros et difficile à éditer. Du coup, je sauve des données au format csv (tout ce qui est inventaire, et état des personnages), mais mon but est que ça puisse facilement être édité à la main. Et l'endroit où je sauve changera probablement d'ici la fin du prototypage.
Pour ma part, j'ai fait la sauvegarde au moment où j'ai géré le changement de scène. Savoir quelles informations sont persistantes entre, en gros, la carte du monde et la carte des combats, était important. Mais clairement, je ne souhaite pas sauver des données comme la position des différents gameobjects.

[war-p]

Alors d'un point de vue plus technique tu peux utiliser les décorations de classe Serializable qui permet d'ajouter quelques méthodes permettant de transformer t'es classes en format lisible (de mémoire c'est du json) et de transformer ces fichiers texte en objet .net. après tu as aussi un utilitaire (je crois que c'est avec unity pour le coup mais je suis pas sûr, je peux reregarder, ça fait longtemps que j'ai fait mon système de sauvegarde ) qui te permet de sauver ces fichiers textes sur le pc en format binaire.

[SalsifiNoir]

Merci pour vos réponses.
Mon idée c’était d’avoir des fichiers de save pas éditables mais si le json est suffisant par exemple ça me va.

Je veux sauvegarder variables du joueur + position des unités et leur statut.
Je me demande s’il faut aussi sauvegarder ce que fait l’IA ou on considère qu’elle reboot et s’adapte à la situation du moment.
J’avais en tête de pas sauvegarder non plus les actions d’attaque et autres hors joueur.

[Grosnours]

Encore une fois cela dépend totalement, est-ce que ton algo d'IA est déterministe (si tu la place dans la meme position elle agira exactement pareil) ou pas ?
Si oui, tu es peinard.
Le principe de la save est de pouvoir restaurer un état précédent du jeu. Ce qui est contenu dans cet état et les données nécessaires à sa restauration dépendent de la manière dont est construit le jeu.
En ce qui concerne les fichiers de sauvegarde eux-mêmes, tu peux les compresser, les obfusquer, les crypter ou les garder en ligne. Ou rien de tout cela.
Au-delà des saves de parties, il faudra aussi que tu fasses peut-être des sauvegardes de cartes ou de scores globaux ou autres, et là une BDD pourrait être utile.

Ici aussi on fait de la sérialisation/désérialisation de JSON pour les saves qui sont elles hostées sur un serveur adossé à une BDD. Pour le serveur le contenu de la save (à l’intérieur de la coquille JSON) est une boite noire. Unity accède au serveur via des points d'accès prédéfinis.

[schouffy]

Comme dit Grosnours c'est vraiment spécifique à ton game design, mais je pense que c'est important d'avoir pour objectif de sauvegarder le moins de choses possible. Moins tu cherches à faire de choses, moins tu risques d'avoir de problèmes.
Réfléchis notamment à ton type de sauvegarde dans ton GD. Une sauvegarde à des points fixes dans des safe rooms à la Resident Evil te permet de sauvegarder BEAUCOUP moins de choses qu'un système de quicksave par exemple.

[LDiCesare]

Pour le côté déterministe, il faut bien penser à sauver la graine et l'état des rng si tu veux prendre ça en compte. Ca implique de gérer assez proprement tous tes jets de dés et de bien utiliser les mêmes api partout.
Maintenant, tu as aussi des jeux qui proposent de regénérer la graine à la reprise de sauvegarde ou pas.