Créer son jeu avec Unity3D !

**Gafda** · 02/02/2016, 17h32

Envoyé par Zevka

Tu as déjà créer ou instanciés des Gameobjects de manière procédurale ?

C'est déjà instancié, cependant c'est ça le problème. Sérialiser des objets simples ça va, mais sérialiser un objet qui contient des composants Unity là pour le coup ça semble assez compliqué à mettre en place. Après, rien ne m'empêche de recréer les composants à partir des données sauvegardées, mais il faut alors se poser la question "Est-ce performant de toujours détruire et recréer des GameObjects?"

**Ravine** · 02/02/2016, 17h35

http://www.archmagerises.com/news/20...ion-in-unity-c
http://forum.unity3d.com/threads/ser...gapost.155352/
et

Bonne lecture, et bon visionnage.

**Grhyll** · 02/02/2016, 17h35

Beh si j'ai bien compris, les prefabs sont là pour ça

Tu as ton objet "type" en prefab, tu as une pool d'instances inactives, et dès que tu as besoin d'un, hop tu l'actives, tu l'initialises avec tes data, il se met à jour, et c'est parti \o/

Edit: Ravine, trop rapide pour moi ^^' Je suis fan du Megapost des best practices sur la serialization, j'y ai déjà étalé ma bêtise et mon ignorance deux ou trois fois :P

**Gafda** · 02/02/2016, 18h48

Owai merci

**Hyperpenguin** · 04/02/2016, 10h21

Hein salut, petite question, dans unity, y'a un façon simple de creer un espace sur une partie de l'ecran, et d'y charger le contenue d'une scène ou du moins une vu de la scène? En fait carrément un écran splitté finalement, mais ou l'on pourrait charger dynamiquement des trucs. Je sais pas si c'est très clair. C'est pour faire apparaître des mini-jeux différent sur une partie de l'écran.

**Gafda** · 04/02/2016, 11h53

Tu peux mettre 2 caméras et changer le Viewport Rectangle pour avoir plusieurs "trucs"

**Adu** · 04/02/2016, 13h31

D'ailleurs c'est pas comme ça qu'on fait pour un GUI et avoir une minimap en surimpression ?

**Hyperpenguin** · 04/02/2016, 15h02

Actuellement on procédé comme suit: on a nos mini-jeu dans une scène séparé, et on fait un loadsceneadditive en rentrant et en scalant les objets comme on veut. J'ai des décalages un peu bizarre et je voulais savoir s'il y avait plus simple/ propre.

**schouffy** · 04/02/2016, 17h34

Met tout sur la même scène en éloignant bien les différents éléments, et met 2 caméras ouais. C'est la bonne méthode je pense.

**Grhyll** · 05/02/2016, 07h21

Pas forcément besoin d'éloigner les éléments, avec les culling mask ça peut même être complètement superposé

(C'est généralement le cas de la UI.)

**Metalink** · 06/02/2016, 03h19

Ptite question Unity : j'ai fais une appli toute conne avec une image qui balance un son quand on clique dessus (avec le système d'UI), mais dès que je compile un .apk il fait 20 mo, une idée de comment optimiser un peu ça ?

**Grhyll** · 06/02/2016, 09h10

Tu passeras pas en-dessous d'un poids minimum avec une build Unity hélas :/ Je suis pas certain qu'il y ait moyen de vraiment passer sous la barre des 20mo, à moins de faire des trucs bizarres de sorcellerie :/

**Metalink** · 06/02/2016, 10h58

J'imagine bien que ya les libs de base d'Unity mais quand même, je trouve ça énorme 20mo en fait ...

**schouffy** · 06/02/2016, 11h39

Ben le truc c'est que pour faire une appli qui lance un son quand tu clic sur une image, Unity c'est un très mauvais choix

Tu as très exactement pris un rouleau compresseur pour étaler une pâte a pizza.

**Metalink** · 06/02/2016, 12h25

Ah oui non clairement l'aurait mieux vallu le faire en natif.
Mais c'est juste que j'ai fait une jam sous Unity le WE dernier et je voulais "tester" vite fait l'export Android avec une application débile

Edit : tiens je vais essayer avec GameMaker pour voir si c'est aussi simple (j'y crois pas trop) et moins lourd (je pense)

**schouffy** · 06/02/2016, 12h39

Je crois que sous Android tu peux atteindre une dizaine de Mo (j'avais fait un jeu avec quelques textures dedans qui en faisait 15). Check les architectures compilées, parfois il y en a plusieurs et c'est inutile (enfin y'a très peu de Android pas ARM).
https://www.reddit.com/r/Unity3D/com...e_for_android/
Mais pas moins.

- - - Mise à jour - - -

Tiens j'en profite pour poser une question.
Est-ce que vous connaissez une façon "efficace" de raycaster un objet mais vers "n'importe où dans le collider", pas juste vers le centre. Un schéma comme c'est pas clair :

A gauche, c'est le comportement de base, je raycast depuis moi vers l'ennemi. Comme y'a un mur entre, je ne vois pas l'ennemi.
A droite, c'est un comportement plus précis car si je ne vois pas le centre de l'ennemi mais une autre partie du collider, je le vois quand même. Mais faudrait matraquer de raycast pour faire ça. Est-ce qu'il existe une méthode plus "efficace" ?

**Louck** · 06/02/2016, 13h52

J'ai le même problème sur mon projet, sachant que je pratique très souvent le raycasting (pour l'IA). Ce qui est très coûteux.

Je n'ai pas eu le temps d'y réfléchir pour une solution à ce problème.
Par contre j'avais essayé d'utiliser un triangle au lieu de plusieurs raycasts pour tester, mais c'était pire

.

Une chose que tu peux faire, c'est déjà limiter le nombre de raycasts par 4 par entité, en ne visant que les recoins de la zone de collision (top-left, top-right, bottom-left, bottom-right). Ensuite, tout dépend de la précision que tu veux apporter à ton test (par exemple en rajoutant un raycast au centre, au cas où si l'entité peut se retrouver derrière un trou)

.

**Sahnvour** · 06/02/2016, 13h56

Tu peux calculer la projection de ton objet sur un plan 2D vu depuis ta camera (ou autre) et sampler plusieurs directions qui tombent dedans ?
Unity a peut-être un moyen de faire ça en prenant en compte l'occlusion culling, ou avec des tricks obscurs à base de stencil buffer et compagnie.

**Gafda** · 06/02/2016, 14h04

Si c'est en 2D tu peux repérer les coins de ton sprite/objet (.Sprite.bounds) et faire un raycast uniquement sur ces points. L'idéal serai de récupérer ça sous forme de rectangle (4points + le milieu à la rigueur)
De plus, si tu es dans une grille alors là tu peux utiliser le rectangle précédent et regarder si la droite tracée passe par la case que tu désire "voir", donc plus besoin de raycast, juste des vecteurs suffisent.

Autre solution, tu traces un cône, et tu regardes si ta case est dans ce dernier. Relativement efficace dans une grille carrée

**schouffy** · 06/02/2016, 14h26

Je vois, y'a pas de méthode miracle quoi.
Je vais partir sur 3 raycast (un au milieu, un à droite, un à gauche). Ce n'est pas parfait car si par exemple il y a des piliers ou barreaux entre moi et le méchant, il peut ne pas me voir.
Si je trouve une meilleure façon je raconterai ici.

**Gafda** · 06/02/2016, 14h58

Envoyé par schouffy

Je vois, y'a pas de méthode miracle quoi.
Je vais partir sur 3 raycast (un au milieu, un à droite, un à gauche). Ce n'est pas parfait car si par exemple il y a des piliers ou barreaux entre moi et le méchant, il peut ne pas me voir.
Si je trouve une meilleure façon je raconterai ici.

Je suis intéressée si t'as une meilleure méthode

**Ravine** · 08/02/2016, 14h36

En terme d'optim, la regle numero 1 c'est: la facon de faire quelque chose le plus rapidement possible est de ne pas le faire.

Donc toujours essayer de penser son probleme d'une maniere globale, d'eliminer les cas les plus courants le plus rapidement possible et rafiner petit a petit.

@Louck
pour l'IA:
- le faire toutes les X millisecondes plutot qu'a chaque frame. Je partirai sur un truc du style "AI Frequency", qui est une propriete qui peut varier (ca te permet de regler ca en testant avec tes data et ton contexte). Genre 30hz d'update c'est un tick d'AI toutes les 33ms. C'est peut etre un peu too much
- faire un tick en fonction de la distance. Plus tu es loin du point of interest (le joueur?), moins tu as besoin d'update. Ca regle aussi le probleme de detection. Si tu es en dehors du detection range, hop, pas d'update de visibilite.
- faire des groupes pour update tes AI en asynchrone. Genre 5 groupes qui s'update chacune leur tour. Au lieu d'update toutes tes AI a chaque frame, tu en update 1/5eme.

pour la visibilite, grosso modo les memes trucs.
- On degrossit sur la distance: un SquareMagnitude des 2 positions devrait te dire si ce que tu essaies de voir est dans ton visible range/degrossit sur le frustum view (aucune idee lequel est le plus simple/rapide. Intuitivement je dirais la distance)
- uen premiere passe avec un volume de detection (si tu n'as pas acces au frustum). Tu peux avoir un trigger collider attache au game object, et avoir un trigger collider sur ton "detecteur". Si l'un declenche l'autre, il s'ajoute a une liste des "objets a verifier plus finement si je peux les voir".
- Avec les quelques objets a verifier qu'il te reste, l'approche des raycast decrite plus haut fonctionne bien. Regarde quels sont tes cas de detection les plus courants, et traite les dans cet ordre. Un early return vaut mieux que de checker tous les raycasts et decider a la fin. Par exemple, on note Player Transform Position vs Target Transform Position. Si ca hit, return true. Si non, check Target Position + Up offset (le top edge de la collision box/capsule/whatever), si oui, return true, si non, etc.

Ne pas oublier que les RayCast peuvent gerer les layers. Vous pouvez definir votre grille comme "SeeThrough" et ignorer les objets qui appartiennent a cette categorie dans votre detection.

Apres je vous balance ca comme ca, je n'ai aucune idee de votre contexte, si vous etes en 2d/Top Down, en FPS, en 3rd person, etc.

**schouffy** · 08/02/2016, 14h57

Envoyé par Ravine

Ne pas oublier que les RayCast peuvent gerer les layers. Vous pouvez definir votre grille comme "SeeThrough" et ignorer les objets qui appartiennent a cette categorie dans votre detection.

A propos de ça, je suis amoureux du type LayerMask et son rendu dans l'inspecteur <3
Pour le reste, je suis content de voir que je n'ai rien "raté" dans le sens où j'ai envisagé tout ce que tu mentionnes.
Les opérations "toutes les X millisecondes" plutôt que chaque frame, j'en use et abuse grâce aux WaitForSeconds des coroutines. Je ne sais pas quel impact à a sur les perfs par contre, ni sur l'allocation mémoire (cf blog post de Ghryll où il semblait dire que les coroutines GC à fond).

**Ravine** · 08/02/2016, 15h13

Faut "optimiser" quand c'est necessaire. L'important c'est de generer les bonnes data, et que le code soit maintenable. Y'a une chouette video sur l'optim, et le mec a des reflections super importantes, dans le sens ou on donne la responsabilite de la performance au code, alors que c'est partage entre le code, le hardware, et les data

**Grhyll** · 08/02/2016, 15h35

Après ça dépend aussi pas mal de là où tu es bottleneck ! Moi j'en suis arrivé à faire la chasse aux allocs pour mon jeu mobile parce que ça faisait des sautes de fps, mais le jeu PC/PS4 sur lequel je travaille avec ma boîte, on serait plutôt inclinés vers les performances. Comme dit plus ou moins Ravine (c'est comme ça que j'interprète en tout cas ^^), y a un juste milieu à trouver, et passer des heures à chercher la petite bête risque de ne pas toujours être très rentable (à tous les niveaux) !
Du coup, si tu n'as pas de soucis de garbage actuellement, continue sans hésiter avec tes coroutines si tu es à l'aise avec et qu'elles ne posent pas de problème ; et si un jour tu t'aperçois qu'elles posent soucis (peu probable si tu ne vises pas le mobile), tu pourras éventuellement y faire quelque chose

**Louck** · 08/02/2016, 16h17

@Louck
pour l'IA:
- le faire toutes les X millisecondes plutot qu'a chaque frame. Je partirai sur un truc du style "AI Frequency", qui est une propriete qui peut varier (ca te permet de regler ca en testant avec tes data et ton contexte). Genre 30hz d'update c'est un tick d'AI toutes les 33ms. C'est peut etre un peu too much
- faire un tick en fonction de la distance. Plus tu es loin du point of interest (le joueur?), moins tu as besoin d'update. Ca regle aussi le probleme de detection. Si tu es en dehors du detection range, hop, pas d'update de visibilite.
- faire des groupes pour update tes AI en asynchrone. Genre 5 groupes qui s'update chacune leur tour. Au lieu d'update toutes tes AI a chaque frame, tu en update 1/5eme.

A l'exception d'exécuter le code en asynchrone, j'ai déjà mis en place un timer et une limitation sur la distance du raycast

.

Mon vrai problème par contre, c'est que j'invoque trop le raycast pour tester un peu tout et n'importe quoi. Je pense qu'il y a moyen de limiter l'utilisation en réfléchissant un peu plus à ce que je fais.

Sinon, je pensais simplement à faire du caching pour enregistrer le résultat d'un traitement que je répète un peu trop souvent (et qui sera renouvelé par un timer beaucoup plus important).

**schouffy** · 08/02/2016, 17h23

Quand tu vois des trucs comme Left 4 Dead 2 qui mitraillent de raycast pour chaque zombie, parfois tu te dis que t'es large quand même

**Louck** · 08/02/2016, 18h39

Je pense surtout qu'ils ont un système de pathfinding beaucoup plus simple que le mien

.

**Molina** · 08/02/2016, 18h49

Bon salut les canards.

J'avais déjà commencé un prototype, avant mon cambriolage, et je compte m'y remettre depuis le début vu que ça y' est je suis stabilisé professionnellement ( et que j'ai acheté un ordi).

Je voudrais savoir si mon projet est faisable pour une seule personne ou si je vise trop haut. En gros, je voudrais faire un jeu à la delver (http://www.delvergame.com/) plus porté sur le RP que l'action, avec feuille de stat, ouverture d'une box avec choix multiple pour certaines actions ( par exemple : ouverture de porte verrouillées -> la défoncer, crocheter, mettre le feu; ce genre de chose) et boîte de dialogue.
Le tout dans une seule et même ville.

J'ai plutot l'impression que le facteur limitant sera les sprites 2D plutôt que le codage mais je peux me tromper.

**Grhyll** · 09/02/2016, 07h39

Ca dépend de la taille de ta ville, et ça dépend du temps que tu es prêt à y investir

Techniquement c'est faisable, si tu as la motivation et que tu parviens à la garder d'un bout à l'autre, mais ça a l'air d'être pas mal de boulot quand même !

Discussion: Créer son jeu avec Unity3D !

Outils de la discussion

Règles de messages