Créer son jeu avec Unity3D !

**Louck** · 09/02/2016, 09h03

A première vue, c'est surtout un jeu qui a beaucoup de contenu (objets, monstres, décors, sprites, etc...).

Après si tu veux te faire une idée si c'est un très gros boulot ou non, tu peux déjà lister les fonctionnalités que tu veux intégrer dans ton jeu: système de combat, équipement, magasin, et j'en passe.

A partir de là, tu auras déjà une petite idée de ce qu'il faut coder pour ton jeu... pour produire un prototype

. Avec un peu plus de travail, tu finiras par produire ta première version alpha de ton jeu.

Mais ce n'est que la version alpha

.
Tout dépendra ensuite de ton objectif (si c'est produire un tout petit jeu, même un peu bugué, ou quelque chose de plus gros) et à quel point tu veux peaufiner ton bébé.

**Grhyll** · 09/02/2016, 09h13

J'ai publié un nouveau blog post qui illustre quelques techniques pour créer ses outils editor pour Unity, avis bienvenus !
http://3-50.net/make-your-tools-in-unity-editor/

**schouffy** · 11/02/2016, 20h23

Grhyll je suis tombé sur ton article ajd, félicitations !!

http://gamasutra.com/blogs/GrhyllJDD...ity_editor.php

**Grhyll** · 11/02/2016, 22h57

Yay il a été partagé sur les réseaux sociaux (comme celui d'avant d'ailleurs) \o/ Je suis kontan

**Poussin Joyeux** · 15/02/2016, 10h18

Hier j'ai joué à Braid et quelques temps avant à Life is Strange. Et ces deux jeux permettent de remonter le temps en conservant les actions du reste de l'environnement.
Savez-vous comment c'est géré ce genre de trucs?

Parce que s'il faut sauvegarder tous les déplacements de tous les objets en permanence, ça peut faire une tonne de variables en mémoire...

Dans le cas de Life is Strange, on n'a pas tout le temps la possibilité de revenir en arrière donc ça limite la charge. Par contre sur Braid (et aussi les mésaventures du Professeur Winterbottom si je me rappelle bien), il n'y a pas de limite et on peut revenir dans le passé aussi loin qu'on le souhaite...

**Molina** · 15/02/2016, 11h02

Envoyé par Louck

A première vue, c'est surtout un jeu qui a beaucoup de contenu (objets, monstres, décors, sprites, etc...).

Après si tu veux te faire une idée si c'est un très gros boulot ou non, tu peux déjà lister les fonctionnalités que tu veux intégrer dans ton jeu: système de combat, équipement, magasin, et j'en passe.

A partir de là, tu auras déjà une petite idée de ce qu'il faut coder pour ton jeu... pour produire un prototype

. Avec un peu plus de travail, tu finiras par produire ta première version alpha de ton jeu.

Mais ce n'est que la version alpha

.
Tout dépendra ensuite de ton objectif (si c'est produire un tout petit jeu, même un peu bugué, ou quelque chose de plus gros) et à quel point tu veux peaufiner ton bébé.

C'est bien ce dont j'avais peur.

J'ai trouvé une graphiste qui serait partante par l'univers. Elle fera surtout le concept art (pourquoi pas, c'est gratuit..) et quelques sprites. En fait, pour avoir fait l'inventaire faudrait que je termine vite fait le coté programmation pour me concentrer uniquement sur le remplissage...

Merci en tout cas pour ton avis !

**schouffy** · 15/02/2016, 11h29

Envoyé par Poussin Joyeux

Hier j'ai joué à Braid et quelques temps avant à Life is Strange. Et ces deux jeux permettent de remonter le temps en conservant les actions du reste de l'environnement.
Savez-vous comment c'est géré ce genre de trucs?

Parce que s'il faut sauvegarder tous les déplacements de tous les objets en permanence, ça peut faire une tonne de variables en mémoire...

Dans le cas de Life is Strange, on n'a pas tout le temps la possibilité de revenir en arrière donc ça limite la charge. Par contre sur Braid (et aussi les mésaventures du Professeur Winterbottom si je me rappelle bien), il n'y a pas de limite et on peut revenir dans le passé aussi loin qu'on le souhaite...

Pour le joueur, oui tout est sauvegardé je pense.
Pour les autres éléments, tu peux je pense juste sauvegarder les changements de direction.
De toute façon même si tout était sauvegardé pour tout le monde, ça ne serait pas non plus énorme. On parle pas d'heures de data, quelques minutes au max (et quelques secondes la plupart du temps), tout ça représentera au pire quelques Mo de data.

**Louck** · 15/02/2016, 11h32

Envoyé par Poussin Joyeux

Hier j'ai joué à Braid et quelques temps avant à Life is Strange. Et ces deux jeux permettent de remonter le temps en conservant les actions du reste de l'environnement.
Savez-vous comment c'est géré ce genre de trucs?

Parce que s'il faut sauvegarder tous les déplacements de tous les objets en permanence, ça peut faire une tonne de variables en mémoire...

Dans le cas de Life is Strange, on n'a pas tout le temps la possibilité de revenir en arrière donc ça limite la charge. Par contre sur Braid (et aussi les mésaventures du Professeur Winterbottom si je me rappelle bien), il n'y a pas de limite et on peut revenir dans le passé aussi loin qu'on le souhaite...

A mon avis, c'est un peu le même délire qu'un snapshot dans une architecture multijoueurs: Tous les X ticks, tu produis une copie de l'état du jeu ou le snapshot: soit une copie brute (ce qui est le plus coûteux mais le plus simple), soit un différentiel par rapport au précédent snapshot (un peu plus compliqué, mais bien moins coûteux).

En soit, ce n'est pas difficile de copier l'état d'un objet. Le plus difficile néanmoins est de le retranscrire, "d'animer" le retour en arrière.

**Poussin Joyeux** · 15/02/2016, 13h12

Merci pour vos retours!

**schouffy** · 18/02/2016, 13h00

Envoyé par Grhyll

Hop je vous partage un petit article de ma composition sur les allocation de garbage en C# sur Unity, pour ceux que ça pourrait intéresser ! Je vais essayer de le faire tourner un peu sur le net ce soir, mais Canard PC l'a en exclusivité au cas où vous auriez des remarques judicieuses sur comment l'améliorer

http://3-50.net/reducing-memory-allo...ge-collection/

J'aurais une petite question que je pose là, mais à l'avenir tu préfères qu'on commente sur ton blog peut-être ?
Je me demandais si les instanciations d'objets que tu fais initialement plutôt qu'au fil du temps (comme les effets de particules que tu vas réutiliser un peu partout), ne ralentissent pas le lancement du jeu ? Genre freeze une fois le niveau chargé pendant que t'instancies ton tableau de 500 impacts de balles.
Et vaut-il mieux mettre tout ça dans Start ou Awake ?

**Roscopolo** · 18/02/2016, 13h55

L'instanciation des 500 objets est négligeable. En revanche leur existence permanente peut ralentir le jeu de plusieurs façons :

* Si jamais tu réalises d'autres allocations durant le jeu, à un moment le ramasse-miettes va devoir opérer. Et là il aura plus d'objets à visiter que ceux actuellement utilisés. En général pré-allouer n'est donc pas recommandé avec les GC. Mais c'est le bon choix si c'est pour complètement éviter le ramasse-miettes ou si tu réduis significativement le nombre de visites tout en alourdissant peu chacun d'entre elles. Considère que le GC passe après 1Mo alloué et prend deux ou trois frames pour une passe superficielle. Chaque objet pèse 12 octets de base plus les champs.

* Si ce sont cinq cents objets d'Unity (je ne me rappelle plus le type de leur objet de base), il est possible que le moteur les passe en revue à chaque frame. Par exemple pour vérifier s'il faut lever un événement Update ou s'il faut afficher un modèle. Dans ce cas le passage en revue de ces 500 objets causera l'éviction de la moitié du cache L1 (64ko, donc 1000 lignes). Une fois par frame ça doit rester à peu près négligeable. Mais si tu en rajoutes, gare à l'éviction du cache L2 : rien de tel pour tuer les perfs.

Cela dit l'avantage d'une allocation préalable c'est que tes objets sont gentiment alignés dans la mémoire, bien compactés. Donc leur passage en revue implique une lecture en mode burst.

**schouffy** · 18/02/2016, 14h22

500 ou 10000 hein. T'es sûr que c'est négligeable ?
Pour le reste de tes remarques oui je comprends bien qu'il faut faire gaffe que tes objets "dormants" ne font rien.

**Roscopolo** · 18/02/2016, 14h25

Instancier un million d'objets ne monopolisera que la première frame, guère plus. Avec les GC l'instanciation est extrêmement rapide (pas de tas ou autre à gérer ; ce n'est qu'une simple incrémentation). Le premier appel à GC.Collect(), à la fin du chargement, est plus significatif en comparaison.

**schouffy** · 18/02/2016, 14h45

Ah je vois, j'avais à tort compris qu'on "initialisait" (Start ou Awake) les Monobehavior lors de leur instanciation. Alors qu'en fait on ne fait qu'instancier sans rien faire.
Et du coup pour que la méthode Update soit appelée à chaque frame, il faut que l'objet fasse partie de la scène ou simplement qu'il soit instancié et "traîne" qque part dans un Array ?

**Gafda** · 18/02/2016, 14h52

Envoyé par schouffy

Et vaut-il mieux mettre tout ça dans Start ou Awake ?

En fait l'utilisation de Start ou Awake va dépendre de ce que tu veux faire dans ton/tes script(s). Le meiux c'est d'aller jeter un coup d'oeil aux deux liens de la doc. C'est très bien expliqué, et je pense que cela va t'aider à choisir l'un ou l'autre

Personnellement, j'ai une préférence pour l'utilisation de Awake();

EDIT:

Envoyé par schouffy

Ah je vois, j'avais à tort compris qu'on "initialisait" (Start ou Awake) les Monobehavior lors de leur instanciation. Alors qu'en fait on ne fait qu'instancier sans rien faire.
Et du coup pour que la méthode Update soit appelée à chaque frame, il faut que l'objet fasse partie de la scène ou simplement qu'il soit instancié et "traîne" qque part dans un Array ?

Pour que la méthode Update() soit appelée, il faut que l'objet soit actif dans ta scène.
Après, rien ne t'empêche de parcourir ton tableau de scripts pour appeler une fonction lors d'un update d'un autre script.

Je pense que cette vidéo peut t'être utile:

**schouffy** · 18/02/2016, 15h02

Merci à vous deux

**Roscopolo** · 18/02/2016, 16h03

On initialise bien dès l'instanciation à ma connaissance mais le budget CPU pour une frame à 60ips c'est plusieurs dizaines de millions d'instructions et des centaines de mégaoctets de bande passante mémoire en mode burst (beaucoup moins en aléatoire). Ça laisse de quoi voir venir ! Heureusement vu que les jeux parviennent à ridiculiser ces capacités ; je ne cesse de trouver miraculeux le fait que ça fonctionne.

En C++ les allocations sont lentes car elles nécessitent souvent de manipuler de lourdes structures de données (notamment des tas) contenant parfois des centaines de millions d'entrées. Avec un GC on reporte la charge sur le nettoyage.

**Grhyll** · 19/02/2016, 09h21

J'arrive avec un peu de retard, mais tout a déjà obtenu une réponse ^^
Aussi, comme je le disais dans mon article, il n'y a pas d'unique stratégie gagnante, ça dépend des contraintes du support et de ce qui est critique. En tout cas, l'instanciation de mes quelques centaines d'objets en début de jeu ne se voit pas, et ça permet, une fois que le jeu roule, de ne plus rien avoir à créer (bien sûr il y a quand même une sécurité, si on arrive au nombre max, ça en créée d'autres). En plus d'avoir drastiquement réduit les allocations partout où je le pouvais, je fais un Collect manuel dès que possible (lancement du jeu, ouverture du menu pause, écran de game over...), pour éviter que tout se cumule d'une partie sur l'autre.

**Gafda** · 19/02/2016, 19h26

Dites, est-ce que vous avez des articles sur le design d'interfaces avec le nouveau système de Unity ?
J'ai lu la doc Unity, mais je trouve que ce nouveau système est carrément plus compliqué que l'ancien (avec les OnGUI() )

**schouffy** · 19/02/2016, 19h35

http://www.raywenderlich.com/114700/...nity-ui-part-1
les OnGUI c'était le bordel (enfin du peu que j'en ai vu, j'ai peu pratiqué à cette époque), le nouveau système pour docker et s'adapter aux différents écrans c'est pas mal.

**Myron** · 19/02/2016, 22h14

J'ai pas vraiment eu l'occasion de tester l'ancien système pour comparer mais le nouveau est plutôt bien expliqué dans les tuto de la 4.6 qui l'introduisait je n'ai eu aucun mal a m'y mettre.
Par contre ce qui manque c'est du DataBinding.

**schouffy** · 26/02/2016, 20h12

Un peu HS, mais vous utilisez quoi pour le version control de vos projets JV ?
Car on atteint vite quelques Go entre les sons, modèles, textures et assets du store.
Y'a des solution qui peuvent hoster ça gratuitement ou faut forcément payer ? J'ai vu quelques trucs (Bitbucket, Assembla, RiouxSvn,..) mais c'est souvent limité à 500M ou 1G..

**Gafda** · 26/02/2016, 22h40

J'ai testé GitHub, j'ai vite abandonné avec la limitation de taille des fichers. BitBucket est pas trop mal, mais par contre il faut bien faire son .gitignore, parce que le dossier Library est trop volumineux (l'occlusion ambiante est horrible en espace disque...)
Le mieux je pense c'est de faire comme expliqué dans cette vidéo. C'est à dire un SVN pour les ressources graphiques et un git tout simple pour le code.

**schouffy** · 26/02/2016, 22h46

Pourquoi pas tout mettre sur svn dans ce cas ?

**Gafda** · 26/02/2016, 23h51

Envoyé par schouffy

Pourquoi pas tout mettre sur svn dans ce cas ?

Choix perso, je préfère git, je le trouve plus simple pour gérer le code que svn.

**Grhyll** · 27/02/2016, 08h34

Ouaip git va mieux gérer les merges que svn a priori.
Pour ma part j'utilisais Assembla, sauf qu'ils ont revu à la baisse leur programme gratuit, depuis je suis passé sur github pour 12$ par mois, mais j'ai pas vraiment fait d'étude complète du marché, j'ai juste fureté vite fait.
(Au boulot on utilise Assembla, mais je veux pas savoir combien ma boîte paie pour ça !)

**Molina** · 28/02/2016, 13h27

Salut les canards !

J'ai un peut problème, rien de gênant, c'est juste par confort. Quand je clique sur un onglet d'unity, ou plus généralement quand j’interagis avec unity, j'ai des artefacts d'affichage qui apparaissent.
Vous connaissez le problème ?

Exemple, ces petits pixel blancs à gauche de l'image :

**Gafda** · 29/02/2016, 15h09

Jamais eu ce genre de soucis... C'est ptet un problème de pilotes graphiques ?

Bon, je viens désespérément quémander de l'aide pour un problème avec le système d'UI (je suis dessus depuis plusieurs jours, je vais devenir fou!!)
En gros, j'ai une grille avec des cases, et le soucis c'est qu'en jeu les images sont complètement déformés.
En images c'est plus parlant:

Ici on à l'impression que les bords noirs ne sont pas de la même épaisseur alors qu'en réalité si !

Voici l'image utilisée:

J'ai tenté d'explorer plusieurs pistes:

Changer la valeur "pixel per units" => Change rien
Changer la taille des cellules de la grille => Résultat aléatoire, parfois c'est bon, d'autres fois non
Visiblement, plus la texture de la case est grande, moins le problème est présent =>Dois-je activer le "mip map" pour la texture ?
Activer le "preserve aspect" => Change rien
Apparemment, le "canevas scaler" à une influence sur le phénomène

Dois-je changer le "canevas scaler" ?

J'ai d'autres pistes à explorer:

Tenter en faisant des textures uniquement en puissances de 2 (genre 32x32)
Changer les paramètres du canevas, si ça se trouve ça vient de là..

De plus j'ai remarqué que le niveau de zoom à un impact sur ce bug étrange, c'est à dire que plus on est proche, moins l'effet de déformation est visible.

**Hyperpenguin** · 29/02/2016, 15h13

C'est pas une histoire de perspective de camera? Bon c'est l'ui donc c'est peut probable mais bon. Sinon essai en puissance de 2 oui.

**Gafda** · 29/02/2016, 15h25

L'effet est toujours le même.
Est-ce que, par le plus grand des hasard, il faudrait prendre en compte le ratio de l'écran ? Parce qu'en mettant le canevas scaler en "Constant Pixel Size", le problème est corrigé, mais du coup je perds la mise à l'échelle en fonction de la résolution de l'écran.

Discussion: Créer son jeu avec Unity3D !

Outils de la discussion

Règles de messages