# Jeux vidéo > Jeux vidéo (Discussions générales) > Le coin des développeurs >  Unity 2D : Les pièges à éviter...

## Ashley TOUCRU

Salut à tous,
Cela fait un moment que ça me tente de développer un mini-jeu vidéo -sans prétention dans un premier temps, juste pour apprendre. J'ai donc tout naturellement acheté le dernier CanardPC Hors-série qui m'a donné quelques indications sur les pièges à éviter, les outils à disposition etc.
Mon intérêt s'est porté vers Unity qui propose la licence la plus complète et intéressante gratuitement. J'ai pu voir qu'il était possible de créer directement en 2D, et je viens de me visionner quelques tutos qui me font penser que c'est jouable même pour quelqu'un qui part de zéro comme moi.

J'aimerais essayer de développer un premier niveau en plate-forme, dans le genre Limbo, Botanicula etc. Simple afin de comprendre tous les écueils et ne pas me décourager avant d'avoir effectué un quart du travail.  ::P: 

Pour le graphisme, je pense pouvoir me débrouiller en créant d'abord en vectoriel sur Illustrator.

Je me pose toutefois quelques questions : quels sont les pièges à éviter quand on développe en 2D ? Y a-t-il des règles que vous vous êtes créées pour gagner du temps ?
Par exemple, y a-t-il des standards à respecter pour la taille des _tiles_ pour composer le décor ? Est-il préférable de composer le décor avec des _tiles_ ou peut-on créer le décor d'un seul tenant ? Ce genre de choses...

Je suis preneur de tous vos conseils, et vous remercie par avance.  :;):

----------


## Tildidoum

Je suis pas codeur mais pour moi le premier piège c'est le genre que tu as choisi.
Limbo et Botanicula pour ce que j'en sais (pas encore joué), c'est beaucoup de 'cas uniques'. 

Chacun des pièges / énigmes pourra demander beaucoup d'attention : 
une réflexion, des mécaniques, des assets graphiques/sonores, bref chaque fois beaucoup de taf peu (voir pas) ré-utilisable.

En gros avec ce genre là tu pourras faire peu de ré-utilisation, beaucoup moins que si tu partais sur du plateformer orienté action.
Après si c'est pour te faire la main pourquoi pas.. Mais ça représente beaucoup de taf pour peu de contenu, et ça peut être démotivant, surtout si tu es tout seul.

Pour la création des décors ça dépend :
Concrètement mieux vaut privilégier les tiles avec des règles précises, une grille de longueur/ largeur, ça va te faciliter la vie pour le level design.

Mais si tu ne vises pas plus que 2-3 tableaux uniques, c'est pas forcément utile de tout décomposer.
Tu pourras travailler de manière plus spontanée en travaillant chaque ensemble individuellement.

Et tu vises quelle plateforme ? Pc, Android/Ios ?

----------


## Grhyll

Eh bien bon courage pour cette entreprise ^^

Il n'y a pas beaucoup de règles que je me vois donner à quelqu'un qui part de zéro, c'est un peu trop vaste comme sujet pour trouver des exemples précis. Tu vas devoir découvrir par toi-même la plupart de ces règles, quitte à demander un coup de pouce quand tu te penches sur un sujet précis.

Au niveau des tiles, la plupart des appareils mobiles ne supportent pas des textures plus grandes que 2048*2048, et sur PC ça doit être limité à 4096*4096, donc limite toi à ces dimensions. Egalement, c'est mieux de faire des textures en POT (Power Of Two) pour la compression, notamment s'il n'y a pas de transparence (les tiles de bg essentiellement, donc). 

Après il existe des tas de façons d'améliorer le pipeline graphique, mais ce n'est généralement pas par ça qu'on commence. Le "problème" est que, vu que tu pars de zéro, ça risque d'être compliqué pour toi d'estimer à l'avance si tu prends la meilleure orientation, si les outils que tu choisis ne vont pas te bloquer plus tard... Mais si tu commences à vouloir tout savoir sur un sujet avant de l'aborder, tu risques de t'en dégoûter avant même d'avoir pu appliquer ce que tu as appris ^^' Donc je te conseillerai de commencer par quelques tutos (celui-ci par exemple est très bien, et il y en a aussi des proposés par Unity, que je n'ai jamais regardé). Ca va te prendre quelques heures, mais ça te donnera déjà quelques pistes pour avoir une idée de comment t'organiser dans ton projet.

----------


## Ashley TOUCRU

> Je suis pas codeur mais pour moi le premier piège c'est le genre que tu as choisi.
> Limbo et Botanicula pour ce que j'en sais (pas encore joué), c'est beaucoup de 'cas uniques'. 
> 
> Chacun des pièges / énigmes pourra demander beaucoup d'attention : 
> une réflexion, des mécaniques, des assets graphiques/sonores, bref chaque fois beaucoup de taf peu (voir pas) ré-utilisable.
> 
> En gros avec ce genre là tu pourras faire peu de ré-utilisation, beaucoup moins que si tu partais sur du plateformer orienté action.
> Après si c'est pour te faire la main pourquoi pas.. Mais ça représente beaucoup de taf pour peu de contenu, et ça peut être démotivant, surtout si tu es tout seul.
> 
> ...


Merci pour les infos. Pour la comparaison, c'était davantage sur le style graphique que sur le mode de jeu puisque je n'ai pas encore joué ces jeux.  ::P:  Pour la partie technique, je comprends bien que les problèmes viendront au fur et à mesure. S'agissant d'un premier projet sans l'ambition d'en faire un véritable jeu, je partirai peut-être dans un premier temps par tableaux complets car c'est ce qui se rapproche le plus de mon taf. Mon intention est de le créer pour PC. A moins que vous ne m'incitiez à choisir une autre plate-forme si ça facilite les choses.  ::rolleyes:: 

- - - Mise à jour - - -




> Eh bien bon courage pour cette entreprise ^^
> 
> Il n'y a pas beaucoup de règles que je me vois donner à quelqu'un qui part de zéro, c'est un peu trop vaste comme sujet pour trouver des exemples précis. Tu vas devoir découvrir par toi-même la plupart de ces règles, quitte à demander un coup de pouce quand tu te penches sur un sujet précis.
> 
> Au niveau des tiles, la plupart des appareils mobiles ne supportent pas des textures plus grandes que 2048*2048, et sur PC ça doit être limité à 4096*4096, donc limite toi à ces dimensions. Egalement, c'est mieux de faire des textures en POT (Power Of Two) pour la compression, notamment s'il n'y a pas de transparence (les tiles de bg essentiellement, donc). 
> 
> Après il existe des tas de façons d'améliorer le pipeline graphique, mais ce n'est généralement pas par ça qu'on commence. Le "problème" est que, vu que tu pars de zéro, ça risque d'être compliqué pour toi d'estimer à l'avance si tu prends la meilleure orientation, si les outils que tu choisis ne vont pas te bloquer plus tard... Mais si tu commences à vouloir tout savoir sur un sujet avant de l'aborder, tu risques de t'en dégoûter avant même d'avoir pu appliquer ce que tu as appris ^^' Donc je te conseillerai de commencer par quelques tutos (celui-ci par exemple est très bien, et il y en a aussi des proposés par Unity, que je n'ai jamais regardé). Ca va te prendre quelques heures, mais ça te donnera déjà quelques pistes pour avoir une idée de comment t'organiser dans ton projet.


Merci pour ces renseignements. J'avais imaginé que le coup de la puissance de 2 était certainement une contrainte à prendre en compte, mais c'est bien de me le voir confirmer.  :;):  Pour le premier tuto linké, moi qui pensais que les informaticiens étaient des gens rationnels, je suis gâté. Jamais vu une mise en page aussi bordélique !  ::P:  Je regarderai ceux de Unity. J'ai regardé le début de cette série, j'ai trouvé le prof plutôt pédagogue. A voir si ça se poursuit dans les épisodes suivants.  ::):

----------


## Tildidoum

Ah oui ok au temps pour moi si tu parlais juste de références visuelles !
Et tu fais bien de viser PC, c'est moins de contrainte donc plus pratique.

Bha y'a plus qu'à, hésite pas à partager tes progrès  ::):

----------


## Hyperpenguin

Salut,

Je réagis parce que j'ai démarré y'a quelques mois un projet de platformer 2D plus orienté aventure qu'action. Je le devéloppe sur Game Maker mais je peux quand même en tirer quelques trucs. 

Déjà défini bien la partie plate-forme, à savoir ce que tu veux que ton perso puisse faire à terme, sauter, double saut, s'accrocher, courir/marcher, ramper, grimper des échelles ou des escaliers... parfois certains tutos qui vont te présenter les bases du platformer vont te rendre les choses plus difficile par la suite quand aux mouvements un peu plus avancées. Poses-toi la question aussi de si tu veux utiliser le moteur physique d'unity pour le perso, pour des enigmes, ça peut jouer un max sur le ressenti des déplacements du perso.


Pour ce qui est du décors, je voulais commencer par une seul grosse image comme toi, avec des gros objets de décors à placer ou on veut, et des hitboxs qui vont bien au niveau des plate-formes, mais ça m'a posé 3 problèmes:
- je n'ai pas suivi de grille définie pour créer mes objets de décors, donc c'était au visu ou a l'arrache, et après au niveau placement dans le décors j'étais forcé de les placer au pixels près, ce qui peut être fastidieux dans une zone de 1000*1000
- la tâches m'a découragé vu que je suis pas du tout graphiste, j'arrivais pas à me projeter sur tout une zone entière d'un point de vu graphique
- l'éditeur de game maker est pas ultra pratique du coup il fallait parfois supprimer plusieurs objet pour pouvoir en selectionner un seul et le déplacer... Je pense que c'est bien mieux sur Unity mais bon...

Du coup je suis passé en tiles de 32*32 pour le second plan, ce qui me permet de créer des elements de décors sur une petite zone et je suis sur que ça va bien coller avec le reste. Tout mes autres éléments comme les plate-formes, les échelles, les décors particuliers, sont sur des multiples de 16, du coup quand je les place dans le décors je règle la grille sur 16*16 et roule ma poule ça va plus vite. 

Après c'est un décors de ville donc ça ne donne pas forcément un effet de répétition non naturel, ça dépend ce que tu comptes faire aussi. Voilà pour mon retour d'expérience, en espérant que ça puisse être utile.

----------


## Ashley TOUCRU

> Ah oui ok au temps pour moi si tu parlais juste de références visuelles !
> Et tu fais bien de viser PC, c'est moins de contrainte donc plus pratique.
> 
> Bha y'a plus qu'à, hésite pas à partager tes progrès


Rhôôô putain, la pression.  :Mellow2:

----------


## Ashley TOUCRU

> Salut,
> 
> Je réagis parce que j'ai démarré y'a quelques mois un projet de platformer 2D plus orienté aventure qu'action. Je le devéloppe sur Game Maker mais je peux quand même en tirer quelques trucs. 
> 
> Déjà défini bien la partie plate-forme, à savoir ce que tu veux que ton perso puisse faire à terme, sauter, double saut, s'accrocher, courir/marcher, ramper, grimper des échelles ou des escaliers... parfois certains tutos qui vont te présenter les bases du platformer vont te rendre les choses plus difficile par la suite quand aux mouvements un peu plus avancées. Poses-toi la question aussi de si tu veux utiliser le moteur physique d'unity pour le perso, pour des enigmes, ça peut jouer un max sur le ressenti des déplacements du perso.
> 
> 
> Pour ce qui est du décors, je voulais commencer par une seul grosse image comme toi, avec des gros objets de décors à placer ou on veut, et des hitboxs qui vont bien au niveau des plate-formes, mais ça m'a posé 3 problèmes:
> - je n'ai pas suivi de grille définie pour créer mes objets de décors, donc c'était au visu ou a l'arrache, et après au niveau placement dans le décors j'étais forcé de les placer au pixels près, ce qui peut être fastidieux dans une zone de 1000*1000
> ...


Carrément !  ::o:  C'est ce genre d'expérience qui m'invite à découvrir ce monde qui m'est totalement étranger. J'ai regardé pas mal de tutos en 3 jours et j'ai compris comment créer la scène et tout ça. Jusque là ça paraît abordable pour un n00b comme moi. Puis est arrivé le code pour déplacer le personnage, et là 'va vraiment falloir que je m'accroche pour comprendre la logique de la programmation.  :ouaiouai:  Challenge ! J'aime.  ::trollface:: 

Perso je ne veux pas retenir Game Maker pour une raison principale : le fait qu'il utilise un langage qui n'est pas universel. Si jamais, par le plus grand des hasards je parvenais à quelque chose, ça m'embêterait de ne pouvoir le transposer sur un autre logiciel et de devoir tout réapprendre.  ::): 
Je suis partagé sur l'histoire des tiles car il s'agit d'un choix avant tout esthétique : travailler en carré va me contraindre énormément, moi qui ai l'habitude du vectoriel où je peux tracer ce que je veux comme je veux. Par conséquent, je me demande si je ne vais pas travailler -au moins pour les décors- avec des modules un peu plus gros que je pourrai tout de même raccorder entre eux car, comme l'a mentionné justement Tildidum, je voudrais consacrer davantage de temps à l'apprentissage de la programmation plutôt qu'au graphisme où je saurai me débrouiller un peu. Il me faut par conséquent pouvoir réinvestir des parties graphiques pour ne pas redessiner tout sans arrêt.  :;): 
Pour les animations et déplacements du personnage, c'est justement ce qui va me demander le plus d'efforts car j'aimerais, bien sûr, faire ça comme il faut pour ne pas me bloquer des pistes de travail. Ca va pas être de la tarte !  ::P: 

En tous cas, je ne vais pas non plus me mettre trop de pression car j'ai conscience qu'un premier projet risque d'être au moins un demi-fiasco.  ::P:  Mais tout ce que je pourrai apprendre sera une expérience intéressante pour moi.
Merci à vous pour vos précieux conseils. S'il y a d'autres choses qui vous viennent à l'esprit, n'hésitez pas, je prends tout ce qui est bon à prendre !  :;):

----------


## Hyperpenguin

Mon conseil ça serait d'effectivement de commencer simple. Si tu cliques sur ma signature tu peux voir mon premier "jeu" fait sous unity, j'ai mis pas mal de temps quand même, j'ai pas pris trop de temps pour les graphismes, mais ça m'a bien permis de défricher unity et ses possibilités tout en gardant un objectif réaliste. 
Après ça se fait en 48h de game jam ou moins ce résultat, mais bon j'ai pas énormément de temps à y consacrer non plus, j'espère que pour toi c'est le cas!

Les tutos sur le site officiel sont d'ailleurs très bien fait, tu peux piocher un peu partout dedans sans devoirs les suivres de bout en bout et ne garder que ce qui te plait (la partie sur l'animator dans le tutos "Rogue-like" s'applique partout si tu es sur de la 2D et que tu bosses avec des spritesheets (image par image) plutôt qu'avec un personnage articulé que tu peux déplacer comme une poupée).

Je me suis lancé dans Game Maker pour évaluer un peu les possibilités qu'offrait l'outil (et j'ai un peu débordé finalement je n'imaginais pas que ça allait me prendre tout ce temps), et mon constat pour l'instant c'est qu'il ne faut pas être trop ambitieux quand même mais ça facilite grandement la tâche sur plein de point, tout en restant moins complexe qu'Unity, ça permet de pas être noyé sous les informations, au début Unity ça fait peur je trouves. Mais pour le prochain jeu que j'ai en tête je repasserais sur Unity pour tester d'autres choses, ou bien j'évaluerais un autre moteur comme Love2D ou Superpowers même si l'idée de bosser avec une belle interface graphique c'est quand même attirant  ::P:

----------


## lordsupra

Faut vraiment surtout voir qu'Unity son vrai nom c'est Unity3D. La 2D n'est qu'un mode qui n'est venu qu'antérieurement quand il se sont rendu compte qu'un partie de la communauté utilisait l'outil en 2D, ils ont ainsi convertis une partie des concepts 3D en 2D : les hiérarchies de repères appelées transform, l'API physique. C'est pas un truc natif 2D, du coup c'est vraiment une logique à part. Par exemple, j'ai galéré sur des fonctions de clipping d'image.

 A l'inverse, y'a des trucs hérités du système 3D qui sont très pratiques voir impériaux, je pense notamment à l'animator qui est un bonheur à utiliser pour faire vivre assez simplement ces petits bonhommes.

----------


## Ashley TOUCRU

> Faut vraiment surtout voir qu'Unity son vrai nom c'est Unity3D. La 2D n'est qu'un mode qui n'est venu qu'antérieurement quand il se sont rendu compte qu'un partie de la communauté utilisait l'outil en 2D, ils ont ainsi convertis une partie des concepts 3D en 2D : les hiérarchies de repères appelées transform, l'API physique. C'est pas un truc natif 2D, du coup c'est vraiment une logique à part. Par exemple, j'ai galéré sur des fonctions de clipping d'image.
> 
>  A l'inverse, y'a des trucs hérités du système 3D qui sont très pratiques voir impériaux, je pense notamment à l'animator qui est un bonheur à utiliser pour faire vivre assez simplement ces petits bonhommes.


Ce que je trouve super intéressant dans Unity, c'est la possibilité de basculer du mode 2D au mode 3D, et qui permet de gérer la profondeur malgré tout de manière assez simple. Je pense en particulier à la gestion de la parallaxe rendue possible facilement grâce à l'étagement des arrière-plans de manière visuelle. Quant à la mise en animation des personnages, je commence à en comprendre les mécanismes. Il ne me reste plus qu'à mettre les mains dans le cambouis quand j'aurai une idée plus précise de ce que je veux produire.  :;): 
J'ai regardé hier soir, en effet, deux petits tutos du site Unity, et je les trouve plutôt bien faits. Celui sur le Roguelike m'a bien dégrossi le fonctionnement des animations via la création de préfab des personnages. Ensuite, à chaque fois, c'est la partie code qui n'est pas naturelle pour moi, qui me demande le plus de réflexion. Je ne saisis pas toujours toutes les subtilités des fonctions créées.  ::sad::  Or j'ai bien compris que c'était le cœur du programme. 'Va falloir s'accrocher !  ::o:

----------


## Ashley TOUCRU

> Mon conseil ça serait d'effectivement de commencer simple. Si tu cliques sur ma signature tu peux voir mon premier "jeu" fait sous unity, j'ai mis pas mal de temps quand même, j'ai pas pris trop de temps pour les graphismes, mais ça m'a bien permis de défricher unity et ses possibilités tout en gardant un objectif réaliste.


Chais pas si "réaliste" est le meilleur qualificatif pour ce jeu.  ::P:  Une simu de gobage de pneus, c'est original !  :^_^:

----------


## Grosnours

Le truc qui m'avait un peu traumatisé à l'époque où j'avais démarré Unity c'était les trouzemilles systèmes de coordonnées, les caméras, les résolutions, ratio d'image et la question d'avoir bien tous ses assets "pixel perfect". Des trucs qui étaient évident en AS et qui là ne l'étaient plus trop vu la foultitude d'options.
Heureusement ils se sont bien améliorés de ce point de vue là entre temps mais fait bien gaffe à ces questions qui peuvent paraître un peu triviales car elles sont importantes malgré tout.

Tu verras, Unity est assez fun à utiliser de par son aspect un peu lego où tu peux rajouter un peu tout à un peu n'importe quoi et contourner pas mal de codage via l'interface graphique. Et puis cela offre une bonne porte pour apprendre un peu de C#.  ::):

----------


## Ashley TOUCRU

Merci pour ces remarques. Je me demandais justement cet aprèm comment on fixait la taille de la scène dans Unity. Parce que je me dis que, selon l'écran sur lequel on utilisera ensuite le jeu, comment détermine-t-on la définition de l'image ?  ::huh::  Qu'entends-tu par "des assets pixel perfect" ?  ::blink::

----------


## Grosnours

Le "pixel perfect" c'est essayer d'obtenir le fait que 1 pixel de ton asset (ton image si tu préfères) = 1 unité de mesure Unity. Ceci pour éviter les cas où tu va te retrouver avec tes sprites "étirés" ou flous ou autres désagréments.
Quelques ressources à ce sujet qui vont t'aider à comprendre le problème et en partie répondre à tes questions de l'aprèm :
http://tinypixel-studios.com/log-2-p...al-for-unity-5
https://www.youtube.com/watch?v=1czpscg9gC0
http://blogs.unity3d.com/2015/06/19/pixel-perfect-2d/
https://www.reddit.com/r/Unity3D/com...el_perfection/

Tu vois tout cela et tu me dis si tu as encore des questions.  :;):

----------


## Hyperpenguin

> Chais pas si "réaliste" est le meilleur qualificatif pour ce jeu.  Une simu de gobage de pneus, c'est original !


Mais il faut pas manger les pneux, ça rend le lion de mer malade  ::o:   ::o:   ::o: 
(En disant réaliste je parlais de l'ambition  :^_^:  )

- - - Mise à jour - - -




> Le "pixel perfect" c'est essayer d'obtenir le fait que 1 pixel de ton asset (ton image si tu préfères) = 1 unité de mesure Unity. Ceci pour éviter les cas où tu va te retrouver avec tes sprites "étirés" ou flous ou autres désagréments.
> Quelques ressources à ce sujet qui vont t'aider à comprendre le problème et en partie répondre à tes questions de l'aprèm :
> http://tinypixel-studios.com/log-2-p...al-for-unity-5
> https://www.youtube.com/watch?v=1czpscg9gC0
> http://blogs.unity3d.com/2015/06/19/pixel-perfect-2d/
> https://www.reddit.com/r/Unity3D/com...el_perfection/
> 
> Tu vois tout cela et tu me dis si tu as encore des questions.


Je m'étais pas du tout penché sur la question (ça doit se voir) mais en fait ça s'applique que pour les jeux en pixels art? Avec des assets graphique de plus haute résolution, c'est aussi à prendre en compte, à partir du moment ou au moins tout est fait a la même échelle?

----------


## Grosnours

Je pense que c'est un problème qui est important pour les jeux en pixel art effectivement, mais qu'il est toujours bon quel que soit son type de jeu de maîtriser de bout en bout le rendu proposé; ce qui fait qu'on ne peut pas vraiment y échapper quel que soit le jeu développé en 2D.
Perso j'essaie de bosser avec les résolutions d'assets les plus hautes possibles (il vaut toujours mieux réduire qu'agrandir) ce qui m'amène à manipuler des backgrounds en 4000*2500 tout en étant un manique du rendu le plus parfait possible.

Untiy 5 a permis de simplifier un peu les choses en intégrant par exemple nativement des scripts de redimensionnement aux canevas mais tout n'est pas encore suffisamment transparent pour qu'on puisse ignorer ce genre de souci.

----------


## Longwelwind

> Le "pixel perfect" c'est essayer d'obtenir le fait que 1 pixel de ton asset (ton image si tu préfères) = 1 unité de mesure Unity. Ceci pour éviter les cas où tu va te retrouver avec tes sprites "étirés" ou flous ou autres désagréments.
> Quelques ressources à ce sujet qui vont t'aider à comprendre le problème et en partie répondre à tes questions de l'aprèm :
> http://tinypixel-studios.com/log-2-p...al-for-unity-5
> https://www.youtube.com/watch?v=1czpscg9gC0
> http://blogs.unity3d.com/2015/06/19/pixel-perfect-2d/
> https://www.reddit.com/r/Unity3D/com...el_perfection/
> 
> Tu vois tout cela et tu me dis si tu as encore des questions.


Je suis pas sûr qu'il faille absolument que 1 unités d'Unity = 1 pixel, mais je pense qu'il est important de faire en sorte qu'une unité soit une valeur significative.
Genre si tu fais un jeu avec des tiles, essayer de faire en sorte qu'une tile = une unité Unity. Ca permet aussi de faciliter l'écriture des scripts (tu dois pas te trimballer une constante de taille partout dans les calculs logiques/graphiques).

----------


## Ashley TOUCRU

J'ai parcouru tes liens très rapidement, mais ça m'a éclairé davantage sur le concept. Ça se rapproche un peu de ce que l'on fait en responsive design pour le web, cette méthode qui consiste à travailler avec des multiplres pour faciliter le redimensionnement. Perso, je suis parti sur une réalisation qui n'est pas du pixel-art. Pour tout dire, mon habitude à travailler en vectoriel sur Illustrator m'incite à partir sur du graphisme que je maîtrise un minimum pour ne pas perdre mon énergie là-dessus. Du coup, partant de vectoriel, n'importe quelle dimension peut être générée quand je le souhaite. Je suis parti sur une animation du personnage en 100x100px. Ça vous paraît réaliste ou il vaut mieux faire plus grand quitte à rééchantillonner à la baisse ? Sachant que j'envisageais une scène de 1920x108 si possible…  ::unsure:: 

- - - Mise à jour - - -




> Je suis pas sûr qu'il faille absolument que 1 unités d'Unity = 1 pixel, mais je pense qu'il est important de faire en sorte qu'une unité soit une valeur significative.
> Genre si tu fais un jeu avec des tiles, essayer de faire en sorte qu'une tile = une unité Unity. Ca permet aussi de faciliter l'écriture des scripts (tu dois pas te trimballer une constante de taille partout dans les calculs logiques/graphiques).


Dis donc, toi. reste correct, hein.  ::(:  J'ai rien compris.
*Edit :* Plus sérieusement, si j'ai bien compris il faut -de préférence- que mon sprite que j'ai créé en 100x100px soit affiché en 100x100px dans Unity. Si la taille ne correspond pas, j'ai intérêt à redimensionner mon sprite pour qu'il corresponde à sa vraie taille dans le jeu, ou éventuellement un multiple. J'ai bon ?  ::huh::

----------


## Grosnours

> Je suis pas sûr qu'il faille absolument que 1 unités d'Unity = 1 pixel, mais je pense qu'il est important de faire en sorte qu'une unité soit une valeur significative.
> Genre si tu fais un jeu avec des tiles, essayer de faire en sorte qu'une tile = une unité Unity. Ca permet aussi de faciliter l'écriture des scripts (tu dois pas te trimballer une constante de taille partout dans les calculs logiques/graphiques).


Ah oui absolument, désolé si je faisais comprendre le contraire. D'habitude je bosse avec la valeur par défaut qui est de 100 pour le PPU, cela me convient bien pour de grandes textures.  :;): 




> J'ai parcouru tes liens très rapidement, mais ça m'a éclairé davantage sur le concept. Ça se rapproche un peu de ce que l'on fait en responsive design pour le web, cette méthode qui consiste à travailler avec des multiplres pour faciliter le redimensionnement. Perso, je suis parti sur une réalisation qui n'est pas du pixel-art. Pour tout dire, mon habitude à travailler en vectoriel sur Illustrator m'incite à partir sur du graphisme que je maîtrise un minimum pour ne pas perdre mon énergie là-dessus. Du coup, partant de vectoriel, n'importe quelle dimension peut être générée quand je le souhaite. Je suis parti sur une animation du personnage en 100x100px. Ça vous paraît réaliste ou il vaut mieux faire plus grand quitte à rééchantillonner à la baisse ? Sachant que j'envisageais une scène de 1920x108 si possible… 
> 
> *Edit :* Plus sérieusement, si j'ai bien compris il faut -de préférence- que mon sprite que j'ai créé en 100x100px soit affiché en 100x100px dans Unity. Si la taille ne correspond pas, j'ai intérêt à redimensionner mon sprite pour qu'il corresponde à sa vraie taille dans le jeu, ou éventuellement un multiple. J'ai bon ?


En gros il faut que tu adaptes ton PPU, ta caméra orthographique, tes canevas et tes textures pour que le rendu de ton sprite correspondent parfaitement à sa source. A toi de voir les valeurs qui te conviendront le plus, tu peux jouer un peu avec cela.
Après il faut aussi que tu te décides sur le système de coordonnées à utiliser, il en existe plusieurs en parallèle dans Unity. Par exemple si tu utilises plusieurs caméras qui ont des Viewport différents, le même objet aura des coordonnées différentes (enfin encore cela dépend dans quel système de coordonnées). Le scaler du canvas peut aussi avoir un impact.
Heureusement il existe des méthodes en interne pour obtenir les coordonnées dans les différents systèmes, il n'y a donc rien de vraiment compliqué.
Et ensuite il faut que tu assimile les principes de pivot, ancre et autres positionnement...  ::P: 

Je veux pas te faire peur avec tout cela, il n'y a rien de vraiment difficile là dedans, mais c'est juste un ensemble de petits traquenards dans lesquels on peut s'embourber un peu si on ne les connaît pas en avance (j'avais galéré au début  ::sad:: ) quand on découvre Unity.  :;): 

Tiens d'ailleurs il y en a qui font du pognon là dessus : https://www.assetstore.unity3d.com/en/#!/content/41927

----------


## Ashley TOUCRU

> Ah oui absolument, désolé si je faisais comprendre le contraire. D'habitude je bosse avec la valeur par défaut qui est de 100 pour le PPU, cela me convient bien pour de grandes textures. 
> 
> 
> En gros il faut que tu adaptes ton PPU, ta caméra orthographique, tes canevas et tes textures pour que le rendu de ton sprite correspondent parfaitement à sa source. A toi de voir les valeurs qui te conviendront le plus, tu peux jouer un peu avec cela.
> Après il faut aussi que tu te décides sur le système de coordonnées à utiliser, il en existe plusieurs en parallèle dans Unity. Par exemple si tu utilises plusieurs caméras qui ont des Viewport différents, le même objet aura des coordonnées différentes (enfin encore cela dépend dans quel système de coordonnées). Le scaler du canvas peut aussi avoir un impact.
> Heureusement il existe des méthodes en interne pour obtenir les coordonnées dans les différents systèmes, il n'y a donc rien de vraiment compliqué.
> Et ensuite il faut que tu assimile les principes de pivot, ancre et autres positionnement... 
> 
> Je veux pas te faire peur avec tout cela, il n'y a rien de vraiment difficile là dedans, mais c'est juste un ensemble de petits traquenards dans lesquels on peut s'embourber un peu si on ne les connaît pas en avance (j'avais galéré au début ) quand on découvre Unity. 
> ...


J'envisage un modeste plateformer 2D avec scrolling horizontal. J'aimerais pouvoir utiliser un système d'étagement des arrière-plans et premier plan pour générer une parallaxe. Du coup, je me trompe ou les coordonnées de déplacement seront uniquement sur x et y ?  ::huh:: 
Enfin je crois que je vais un peu vite en besogne, je n'ai pas encore regardé comment fonctionne le système de déplacement des caméras dans Unity.  ::rolleyes::

----------


## Hyperpenguin

http://gamedevelopment.tutsplus.com/...ame--cms-21510

Pour le parralaxe, un très bon tuto.

----------


## Grosnours

> J'envisage un modeste plateformer 2D avec scrolling horizontal. J'aimerais pouvoir utiliser un système d'étagement des arrière-plans et premier plan pour générer une parallaxe. Du coup, je me trompe ou les coordonnées de déplacement seront uniquement sur x et y ? 
> Enfin je crois que je vais un peu vite en besogne, je n'ai pas encore regardé comment fonctionne le système de déplacement des caméras dans Unity.


Oui, mais quels x et quels y, ceux de l'écran, ceux du viewport de la caméra, ceux du monde, ceux du GUI ?  ::P: 
Encore une fois il est probable que tu n'ai pas à traiter ces questions vu que tu va démarrer avec un programme tout simple, mais c'est bon de savoir qu'il existe plusieurs systèmes de coordonnées.

Pour la parallaxe le programme tuto space shooter (un peu ancien mais toujours bien) est pas mal dans le genre, cf ici.

----------


## Ashley TOUCRU

Merci pour toutes ces infos.  :;):  J'avais regardé celui-ci qui m'avait paru bien fichu.  ::rolleyes::

----------


## Grosnours

Ah oui, pas mal du tout.  ::): 
C'est un des gros avantages de Unity, une communauté dynamique qui regorge de tutos. Si jamais t'as une question ou un problème la réponse sera à coup sur sur Internet.

----------


## Longwelwind

> Dis donc, toi. reste correct, hein.  J'ai rien compris.
> *Edit :* Plus sérieusement, si j'ai bien compris il faut -de préférence- que mon sprite que j'ai créé en 100x100px soit affiché en 100x100px dans Unity. Si la taille ne correspond pas, j'ai intérêt à redimensionner mon sprite pour qu'il corresponde à sa vraie taille dans le jeu, ou éventuellement un multiple. J'ai bon ?


Zut, j'ai pas compris non plus ce que tu veux dire.  ::sad:: 

T'as plusieurs paramètres que tu peux modifier dans tes sprites et dans Unity, notamment le "Units per pixel" d'Unity (paramètres du Sprite dans tes assets).

Supposons que tu aies des tiles de 132 pixels. Tu peux te dire simplement que 1 pixel = 1 unités Unity et que donc tu vas donc mettre le "Units per pixel" à 1. Quand tu va coder ton jeu, pour mettre un tile à la position (4, 5), tu fais:


```
this.transform.position = new Vector3(4, 5) * 132;
```

Et vu que tu es un grand codeur qui se soucie des bonnes pratiques, tu va isoler la constante dans une variable


```
this.transform.position = new Vector3(4, 5) * SIZE_SPRITE;
```

A chaque calcul de position, tu devras pas oublier de rajouter cette constante dans tes calculs. Ça peut venir alourdir des expressions.

Maintenant, tu pourrais te dire que tu veux que 1 unité Unity = 1 "case" de ton jeu. Alors là, tu mettras le "Units per pixel" à la taille d'un sprite (ici 132), et pour mettre une tile à la position (4, 5), tu fais:


```
this.transform.position = new Vector(4, 5);
```

Ça permet d'éviter de se trimballer une constante "graphique" dans ton code. Les scripts concernant la logique de ton jeu travailleront avec une espèce d'unité normalisée.

C'est un p'tit détail, mais c'est une bonne petite pratique qui peut rendre plus facile le débuggage. C'est plus facile de voir une entité à la position (14, 28), que d'en voir une à la position (1848, 3696).

----------


## Ashley TOUCRU

:Cryb:  Je crois que je n'en suis pas encore si loin dans la compréhension de Unity.  ::O:  Mais je note pour le moment où je devrai commencer à en tenir compte.  :;): 

*Edit :* OK, je viens de relire deux fois ton message et ça me semble plus clair… Si je fixe l'unité de mon jeu à 132px, chaque "placement" se fera par incréments de 132px, c'est ça ?  ::rolleyes::  Mais du coup, plus les tiles sont gros, moins c'est précis pour positionner des objets, non ?  ::wacko::

----------


## Grosnours

T'es pas obligé de faire tes placements qu'en unités entières non plus...  ::P:

----------


## Longwelwind

> Je crois que je n'en suis pas encore si loin dans la compréhension de Unity.  Mais je note pour le moment où je devrai commencer à en tenir compte. 
> 
> *Edit :* OK, je viens de relire deux fois ton message et ça me semble plus clair… Si je fixe l'unité de mon jeu à 132px, chaque "placement" se fera par incréments de 132px, c'est ça ?  Mais du coup, plus les tiles sont gros, moins c'est précis pour positionner des objets, non ?


Exact. Si tu fais en sorte qu'une unité Unity = 132 pixels de sprites, quand tu voudras monter ton personnage à la tile au dessous, tu devras juster ajouter (0, 1) dans ses coordonnées.

Y'as pas de "précision", les unités d'Unity ne sont pas relatives à autres choses, c'est vraiment à toi de décider de ce que tu veux. Tu pourrais même choisir de faire qu'une case = 0.00001 unités Unity, tu n'aurais pas de problèmes de primes à bord (Tu en rencontreras peut-être par contre si tu utilises le moteur physique d'Unity).

----------


## Ashley TOUCRU

> T'es pas obligé de faire tes placements qu'en unités entières non plus...


Ouais, chuis con !  ::P:

----------


## Ashley TOUCRU

J'ai une question liée à un tutoriel que j'ai regardé (toujours ceux de Casanis) :

Le gars explique qu'il utilise "velocity" pour déplacer son personnage alors qu'il ne devrait pas. J'ai donc cherché un peu la différence avec "translate". Donc si j'ai bien compris les discussions sur le forum Unity, translate n'a pas besoin de rigidbody (ni du moteur physique) et économise donc les ressources, alors que velocity requiert rigidbody et serait donc plus gourmand. C'est ça ?  ::rolleyes::  Donc ça veut dire qu'il vaut mieux utiliser transform.translate pour éviter d'utiliser systématiquement des rigidbody ?  ::huh:: 
Vous avez des habitudes particulières, vous, pour ce genre de choses ?  ::rolleyes::

----------


## Grosnours

A mon sens, tu utiliseras un rigidbody quand tu en auras véritablement besoin.
Commences le plus simple possible et ensuite tu pourras toujours compliquer au fur et à mesure que tu apprends et maîtrises les choses.

----------


## Black Wolf

> J'ai une question liée à un tutoriel que j'ai regardé (toujours ceux de Casanis) :
> 
> Le gars explique qu'il utilise "velocity" pour déplacer son personnage alors qu'il ne devrait pas.


Au contraire, normalement tu ne translate jamais un objet rigidbody non-kinematic (ou définis directement sa vitesse), tu lui applique les forces nécessaire pour le faire bouger comme tu le veux. Je crois que ça a été amélioré avec une version récente d'Unity 5 mais en plus d'effet indésirable, faire un translate sur un rigidbody demandait au moteur physique de recalculer plein de trucs, ce qui était très lent niveau temps d'exécution.

----------


## Ashley TOUCRU

OK, bon. Merci pour les infos.  :;):  Comme le dit Grosnours, je verrai quand j'en aurai besoin. Je n'en suis qu'à découvrir des tutos.  ::P:

----------


## Grhyll

Plein de bonnes nouvelles qui arrivent pour la 2D ! http://blogs.unity3d.com/2016/06/13/...ental-preview/

----------


## Hyperpenguin

Aw yeah le tile map, cool!

----------


## Louck

> We have also added an Edge-Radius property for BoxCollider2D & EdgeCollider2D components







> Tile Map




Dommage que ca arrive tardivement  ::P: .

----------


## Grhyll

On ne réalise l'intérêt des nouvelles features que si elles nous ont manqué par le passé ^^

----------


## Metalink

Le tilemap c'était un des trucs qui m'empêchaient d'envisager Unity pour tous mes jeux en 2D  ::lol::

----------


## Grhyll

Ah c'est dommage, il y avait déjà plusieurs packs sur l'asset store qui le proposaient, il me semble ! (Peut-être des payants ceci dit.)

----------


## Ashley TOUCRU

> Le tilemap c'était un des trucs qui m'empêchaient d'envisager Unity pour tous mes jeux en 2D


Je n'ai encore rien produit de concret, mais j'avoue que j'étais étonné de ne voir nulle part ce genre d'outil dans un logiciel où la grille semble être la base.  ::): 
Sinon, concernant le Edge Radius Collider, je me trompe ou c'est notamment ce qui pourrait éviter que des collisions "bloquent" le déplacement d'un objet en s'accrochant dans un autre objet ?  ::huh::

----------


## Louck

Pour la tilemap, j'utilise déjà ma propre solution avec Tiled. Mais la version d'Unity semble être beaucoup plus intéressante. A essayer  ::): .

Concernant le Edge Radius Collider, ca permet surtout de grossir la zone de collision de certains hitbox... donc celui du EdgeCollider2D, qui n'est qu'un simple trait à l'origine: un objet rapide et petit peut passer à travers très facilement. Ce qui est fort dommage, car ce composant est très pratique pour dessiner les zones de collision d'une map.
Maintenant, en y ajoutant une largeur au trait, les objets auront moins tendance à passer à travers  :;): .

----------


## Grosnours

Ça tombe bien je vais avoir besoin du 9-slice incessamment sous peu.

----------


## Ashley TOUCRU

> Pour la tilemap, j'utilise déjà ma propre solution avec Tiled. Mais la version d'Unity semble être beaucoup plus intéressante. A essayer .
> 
> Concernant le Edge Radius Collider, ca permet surtout de grossir la zone de collision de certains hitbox... donc celui du EdgeCollider2D, qui n'est qu'un simple trait à l'origine: un objet rapide et petit peut passer à travers très facilement. Ce qui est fort dommage, car ce composant est très pratique pour dessiner les zones de collision d'une map.
> Maintenant, en y ajoutant une largeur au trait, les objets auront moins tendance à passer à travers .


Ah OK, merci pour l'explication.  :;): 

- - - Mise à jour - - -




> Ça tombe bien je vais avoir besoin du 9-slice incessamment sous peu.


Ça a l'air vachement intéressant pour se créer des Prefab à volonté.  :;):

----------


## Ashley TOUCRU

Dites, les amis...

Je me pose (encore) une question. J'ai commencé à réaliser quelques éléments graphiques pour tester des trucs, mais je me pose toujours une question liée à la taille (si, ça compte, parfois.  ::rolleyes:: ) : considérant que j'imagine un jeu jouable en plein écran soit une résolution "standard" de 1920x1080, ça signifie que ma fenêtre de travail fait cette résolution. Mais du coup, pour un plate-former à scrolling horizontal, ça signifie que, pour réaliser un niveau entier, je dois faire en sorte que le décor qui défile mesure le nombre de largeurs d'écran x 1080 de haut ? Ca fait un fichier sacrément énorme, ça !  ::o:  Je suppose qu'il est important de réutiliser un maximum d'éléments graphiques pour que le calcul soit moins compliqué pour le rendu final, non ? Du coup, je comprends mieux les screens de OTOT postés récemment.  ::):  Ou alors j'ai rien compris du tout.  ::unsure::

----------


## Poussin Joyeux

En fait, tu ne vas pas faire un gros élément pour couvrir tout l'écran. Tu auras plusieurs éléments que tu disposeras à l'écran, certains que tu répéteras (les plateformes où tu sautes), d'autres que tu feras défiler en boucle (paysage en parallax par exemple, ou bien des nuages...), etc...
Bref au final, ce n'est pas des images de 1920x1080 que tu affiches à l'écran mais un assemblage de plusieurs petites images (et que tu réafficheras à l'écran suivant, etc...). Ca te prendra moins de mémoire et moins de stockage et ce sera aussi plus rapide à charger/afficher (car tu charges une fois en mémoire la petite image et après tu la place plusieurs fois).

Après je ne travaille pas dans le jeu vidéo alors je dis peut-être n'importe quoi  ::P:

----------


## Ashley TOUCRU

> En fait, tu ne vas pas faire un gros élément pour couvrir tout l'écran. Tu auras plusieurs éléments que tu disposeras à l'écran, certains que tu répéteras (les plateformes où tu sautes), d'autres que tu feras défiler en boucle (paysage en parallax par exemple, ou bien des nuages...), etc...
> Bref au final, ce n'est pas des images de 1920x1080 que tu affiches à l'écran mais un assemblage de plusieurs petites images (et que tu réafficheras à l'écran suivant, etc...). Ca te prendra moins de mémoire et moins de stockage et ce sera aussi plus rapide à charger/afficher (car tu charges une fois en mémoire la petite image et après tu la place plusieurs fois).
> 
> Après je ne travaille pas dans le jeu vidéo alors je dis peut-être n'importe quoi


Oui, ta réponse confirme ce que j'ai commencé à préparer : beaucoup de préfab qui seront réutilisés an grande quantité. Mais la question que je me posais portait surtout sur le décor de fond, qui occupe forcément la totalité de l'écran de jeu… ce qui signifie répéter des fonds de grande taille et en grande quantité. Compte tenu qu'on défile horizontalement, ça représente un paquet de pixels sur la totalité du jeu, et un bandeau immense dans Unity. Même en répétant les mêmes sprites, ça ne risque pas de râmer rapidement ?  ::o:

----------


## Longwelwind

Après, tu peux faire un script qui va faire en sorte d'instancier/détruire les fonds qui doivent être affichés. Tu regardes la position de la caméra ainsi que sa taille, et tu en déduis à quel position tu dois placer tes fonds.

----------


## Hyperpenguin

C'est même complètement obligé de faire ça, il faut que tu découpes ton background en un maximum d'éléments, pour pouvoir en tirer un max de chose réutilisable que tu vas instancier quand il faut , et si ça sort du champs, HOP on détruit. Et pour des éléments que tu estime "grand", il suffit par exemple pour une longue bande ou l'on voit le ciel et l'horizon, d'en faire une petite qui va défiler et boucler a l'infini jusqu'a ce que ça doit changer, si ton niveau fait 20 écran de large par exemple, le ciel ne doit pas en faire plus de 2, et c'est le code qui se chargera d'instancier ce ciel derrière le joueur au moment qui va bien et de détruire les morceaux inutiles. 

Je que l'homme de la situation. Je que dossier bleu et vous sur une centaine de tableaux très clairs. 
Vous semaine prochaine et sans faute. Je tellement sur vous... Je clair Luc ne pas ?

----------


## LaVaBo

> En fait, tu ne vas pas faire un gros élément pour couvrir tout l'écran. Tu auras plusieurs éléments que tu disposeras à l'écran, certains que tu répéteras (les plateformes où tu sautes), d'autres que tu feras défiler en boucle (paysage en parallax par exemple, ou bien des nuages...), etc...
> Bref au final, ce n'est pas des images de 1920x1080 que tu affiches à l'écran mais un assemblage de plusieurs petites images (et que tu réafficheras à l'écran suivant, etc...). Ca te prendra moins de mémoire et moins de stockage et ce sera aussi plus rapide à charger/afficher (car tu charges une fois en mémoire la petite image et après tu la place plusieurs fois).
> 
> Après je ne travaille pas dans le jeu vidéo alors je dis peut-être n'importe quoi


Une solution courante, c'est d'utiliser des tiles : des éléments, tous de la même taille, carrés, avec lesquels on va remplir l'écran.
On utilise un tileset, une grosse image sur laquelle se trouvent tous les tiles (ou un set de tiles prédéfinis, par exemple le background d'un niveau donné) et où la position de chaque tile est connue (par exemple en (1,1) c'est du ciel, en (1,2) du gazon, etc)

C'est par exemple comme ça que fonctionnent les marios de la NES, avec en plus une notion de tile blocante ou pas, puisqu'il y en a pour l'arrière-plan, et d'autres pour des obstacles au premier plan - bien évidemment, on ne superpose pas une tile de premier plan par-dessus une tile d'arrière-plan, puisque celle en arrière plan ne sera jamais visible.

----------


## Ashley TOUCRU

OK, merci, j'y vois plus clair sur le principe. Je l'avais déjà assimilé, mais il faut encore que je m'efforce de l'appliquer de manière systématique sur les éléments que j'ai réalisés. Je posterai bientôt un visuel pour vous montrer où j'en suis et qui vous permettra à coup sûr de pointer rapidement tout ce que je dois modifier/améliorer.  :;):  Et ça risque de signifier de tout reprendre.  ::P:

----------


## Grhyll

Si ça t'intéresse et que j'y pense, je te ferai ce week-end une petite capture de mon dernier petit shoot-them-up qui tourne, sur laquelle on voit les éléments se faire ajouter devant/disparaître derrière !

----------


## Ashley TOUCRU

> Si ça t'intéresse et que j'y pense, je te ferai ce week-end une petite capture de mon dernier petit shoot-them-up qui tourne, sur laquelle on voit les éléments se faire ajouter devant/disparaître derrière !


Ouais, bien sûr que ça m'intéresse.  ::lol::  Tout est bon à prendre quand on ne sait rien.  ::):  Justement, ce sytème de choses qui "disparaissent", ça se fait au niveau du code, du coup ?  ::huh::

----------


## Longwelwind

Yep.
A chaque Update, tu regardes la position actuelle de la caméra. Tu la traduis en coordonnées par rapport à la taille de ton background (Si elle se trouve en x = 900 et que ton background fait 400px, tu es a la coordonée x = 3).
Tu sais donc que tu doit créer des backgrounds centrée autour de x = 3*400 = 1200. Si l'écran fait 1920 pixels de large, tu sais que tu dois faire 5 backgrounds (1920 divisé par 400 arrondi au-dessus).
Tu crées donc des backgrounds à ces positions.

Tu retiens dans un Dictionary ceux que tu viens de crées, pour qu'à la prochaine Update, ton code vérifie si un background n'a pas déjà été fait.

----------


## Ashley TOUCRU

> Yep.
> A chaque Update, tu regardes la position actuelle de la caméra. Tu la traduis en coordonnées par rapport à la taille de ton background (Si elle se trouve en x = 900 et que ton background fait 400px, tu es a la coordonée x = 3).
> Tu sais donc que tu doit créer des backgrounds centrée autour de x = 3*400 = 1200. Si l'écran fait 1920 pixels de large, tu sais que tu dois faire 5 backgrounds (1920 divisé par 400 arrondi au-dessus).
> Tu crées donc des backgrounds à ces positions.
> 
> Tu retiens dans un Dictionary ceux que tu viens de crées, pour qu'à la prochaine Update, ton code vérifie si un background n'a pas déjà été fait.


J'ai pas vraiment tout saisi dans le détail, 'faudrait que j'essaie pour me rendre compte. Mais je pense avoir compris le principe.  :;):  Pour le Dictionary, je pense que c'est bien trop tôt pour que je comprenne.  ::P:

----------


## Hyperpenguin

Un dictionnary c'est un tableau en mieux tkt.

----------


## Grhyll

Le gif promis (50Mo la bête) :

https://www.dropbox.com/s/o7o2kt9b1m...anePool.gif?dl

On voit les vagues, et un peu les nuages, qui disparaissent une fois hors-champs et réapparaissent devant. En plus de faire cette rotation, tu noteras que je n'en recréée pas de nouveaux : j'en ai une réserve, je les disable quand je n'en ai pas besoin et je les reenable quand il faut de nouveau en afficher. 

Et en bonus, le script qui fait ça :



```
using UnityEngine;
using System.Collections.Generic;

public class TilesSpawner : MonoBehaviour
{
	public GameObject prefab;

	public float parallaxLevel = 0;

	float parallaxSpeed;

	GroundTile lastTile;

	List<GroundTile> currentTiles;

	// Use this for initialization
	void Start () 
	{
		currentTiles = new List<GroundTile>();
		
		parallaxSpeed = CameraManager.Instance.speed*parallaxLevel/100f;

		GroundTile[] previousTiles = GetComponentsInChildren<GroundTile>();
		for(int i = 0; i < previousTiles.Length; i++)
		{
			previousTiles[i].DisableEntity();
			GameObject.Destroy(previousTiles[i].gameObject);
		}

		InitTiles();
	}

	void InitTiles()
	{
		currentTiles.Clear();

		int tilesCount = 0;

		lastTile = (GroundTile) Spawn();
		lastTile.transform.SetParent (transform);
		currentTiles.Add(lastTile);

		do{
			tilesCount = currentTiles.Count;
			Update();
		}while(currentTiles.Count > tilesCount);
	}
	
	// Update is called once per frame
	void Update () 
	{
		if( (parallaxLevel < 100 
		     && lastTile.transform.position.x + lastTile.width/2f < CameraManager.Instance.GetScreenCenterPosition().x + CameraManager.Instance.cameraWidth + 20)
		   || (parallaxLevel > 100
		    && lastTile.transform.position.x - lastTile.width/2f > CameraManager.Instance.GetScreenCenterPosition().x + CameraManager.Instance.cameraWidth + 20) )
		{
			float sign = (parallaxLevel < 100 ? 1f : -1f);
			Vector3 lastTilePosition = lastTile.transform.position;
			lastTilePosition.x += sign * lastTile.width/2f;
			
			lastTile = (GroundTile) Spawn();
			lastTilePosition.x += sign * lastTile.width/2f;
			lastTile.transform.position = lastTilePosition;
			lastTile.transform.SetParent (transform);
			currentTiles.Add(lastTile);
		}
		for(int i = 0; i < currentTiles.Count; i++)
		{
			if(currentTiles[i].readyToUse)
			{
				currentTiles.RemoveAt(i);
				i--;
			}
		}
	}

	void FixedUpdate()
	{
		if(parallaxLevel != 0)
		{
			for(int i = 0; i < currentTiles.Count; i++)
			{
				Vector3 newPosition = currentTiles[i].transform.position;
				newPosition.x += parallaxSpeed*Time.fixedDeltaTime;
				currentTiles[i].transform.position = newPosition;
			}
		}
	}

	protected virtual PoolableEntity Spawn()
	{
		return PoolManager.Instance.Get(prefab, transform.position);
	}
}
```

----------


## Ashley TOUCRU

> Le gif promis (50Mo la bête)


Merci à toi. J'avais compris le principe, mais là je vois la mise en œuvre.  :;):  'Faudra que je voie ce que ça donne quand je me lancerai dans l'animation proprement dite car je n'avais pas du tout vu cela comme ça.  ::): 
Sinon, histoire d'avancer quand même, j'ai peaufiné ce week-end mes éléments graphiques dans Illustrator, que j'ai retravaillés pour les découper plus facilement. J'aurai bientôt, je l'espère, une base correcte pour tester des choses dans Unity.  :;): 
D'ailleurs, je ne parviens pas à me souvenir du nouvel outil de grille qui est apparu dans Unity récemment. Quelqu'un peut me dire comment on y accède, svp ?  ::):

----------


## Ashley TOUCRU

Salut les amis !

Je reviens à la charge !  ::P:  J'ai avancé sur les graphismes de mon embryon de premier niveau de jeu et j'en suis rendu à un point où je vais devoir bientôt -ou pas- mettre les mains dans le cambouis pour essayer tout ça dans Unity.
J'ai réalisé les visuels en vectoriel sous Illustrator, et je me pose une question :
Sous quel format dois-je exporter mes sprites ? SVG ? Png 8 ou 24 ? Doit/Peut-on utiliser des Jpeg pour les fonds opaques ?  ::huh::

----------


## Grhyll

Alors je suis pas trop dans le côté graphique de la force, mais de mémoire :
- Le svg n'est pas nativement supporté par Unity (pas 100% sûr, et pas impossible qu'il existe des plugins)
- PNG c'est nickel
- Jpeg c'est possible aussi
Ceci dit ça doit pas être trop compliqué à vérifier sur internet, tout ça !

----------


## Roscopolo

> Sous quel format dois-je exporter mes sprites ? SVG ? Png 8 ou 24 ? Doit/Peut-on utiliser des Jpeg pour les fonds opaques ?


Unity se chargera de tout convertir au format natif de la plateforme ciblée (DDS par ex). Donc utilise le format qui t'arrange le mieux parmi ceux supportés. Moi je prendrais PNG plutôt que JPEG, pour éviter les artefacts de compression. Quant à SVG il n'est pas reconnu je crois, en revanche PSD l'est.

----------


## Ashley TOUCRU

Merci pour vos réponses. Je vais faire simple et me contenter de Png.  :;):  J'avais vu cette vidéo que j'avais trouvée intéressante étant donné que j'ai l'habitude de bosser nativement en vectoriel, mais ça risque d'être compliqué et comme c'est pas donné...  ::mellow::

----------


## Enyss

Tiens, les grands gourous d'Unity (boing boing), j'ai un petit problème de collisions... 

voici la situation :


Le problème c'est que de temps à autre, lorsque le perso longe le mur, il se coince sur le bord. Chaque tile a sa BoxCollision2D, vu que les niveaux vont être générés procéduralement (et seront dynamiques)

Si vous avez des idées de solutions...

----------


## Louck

Ahah le bug classique  ::P: . Un bug un peu idiot (made in unity) mais très pénible.

En gros, même si les zones de collisions sont bien côté à côte et sans espaces, le moteur du jeu considère (au fixedupdate près) que ton personnage touche le recoin d'une de ces zones, et qu'il entre en collision. Et étant donné que la hitbox de ton personnage est un BoxCollider, il s’arrête net.

C'est pire pour les jeux de plateformes, où la gravité force le protagoniste à entrer en collision.


Il existe deux solutions à ce problème:

 - Ne pas utiliser plusieurs BoxColliders pour les collisions de map, mais plutôt un seul (ou quelques-uns) EdgeCollider. L’intérêt est de ne pas surcharger le jeu de colliders (optimisation, tout ca). Cependant, le EdgeCollider est très limité en terme de collision (étant donné que ce n'est qu'un "fil"), donc sauf si le jeu n'utilise pas des entités à haute vélocité, il faut faire attention avec ce collider (ou attendre une mise à jour d'Unity).

 - Solution plus simple: Arrondir les recoins de la hitbox du personnage en utilisant le PolygonCollider, de façon à ce que le contact avec le recoin des autres colliders n'immobilisent pas le personnage (par contre, il faut juste s'assurer que le personnage ne se retourne pas en cas de collision).
Comme ca:

----------


## Grhyll

Encore plus simple et économique (mais éventuellement limité en fonction de ce que tu projettes de faire), utiliser un Circle (ou Sphere) collider !

----------


## Enyss

Merci ! c'est grosso-modo ce que j'avais envisagé comme solutions... Déjà je suis content d'avoir correctement deviné la cause.

Finalement, j'utilise la deuxième solution de Louck, ça saute légèrement au lieu de bloquer, mais c'est déjà moins gênant (surtout que c'est en vue de dessus, donc on ne passe pas son temps à longer les colliders).

----------


## Ashley TOUCRU

> Encore plus simple et économique (mais éventuellement limité en fonction de ce que tu projettes de faire), utiliser un Circle (ou Sphere) collider !


Ouaip. C'est ce qu'explique Casanis dans cette vidéo. Je trouve ses tuto super bien foutus. Je pense grandement m'en inspirer pour mon mini-projet :



J'espère que j'ai linké la bonne vidéo, sinon regarde dans sa playlist.  :;):

----------


## Enyss

Voilà à quoi je suis arrivé :




Bon, je suis con, j'ai oublié de montrer la collision du player ^^

----------


## Ashley TOUCRU

> Voilà à quoi je suis arrivé :
> 
> 
> 
> 
> Bon, je suis con, j'ai oublié de montrer la collision du player ^^


J'espère en arriver bientôt à peu près là sans trop de difficultés. Ce serait déjà bien !  ::o:

----------


## saroumana

Question bête : comment faire pour avoir un scrolling fluide avec une camera 2d ?

En fouillant, j'ai tenté diverses méthodes 




> transform.position = new Vector3(transform.position.x +( speedX * Time.deltaTime), transform.position.y +( speedY * Time.deltaTime), transform.position.z);


En modifiant directement la position de la camera




> transform.position = Vector3.Lerp(transform.position, target, 1);
>   transform.position = Vector3.MoveTowards(transform.position, target, Time.deltaTime * speed);


Avec la commande *Lerp* ou *MoveTowards*. Mais a chaque fois y a de légère saccade, c'est loin d’être le scrolling fluide qui ne fait pas mal au yeux.
Du coup, j'ai aussi tenté sans synchronisation verticale, puis en la réactivant et en réglant le framerate a 60fps. En déplaçant la fonction sur *LateUpdate*, *FixedUpdate* ou *Update*, mais rien n'y fait, le déplacement de la camera n'est pas propre.

----------


## Grhyll

J'ai déjà eu des soucis du genre. Est-ce que tu utilises la physique dans ton jeu ? Parfois le déplacement de la caméra en lui-même est clean, mais le déplacement d'objets dans le jeu n'est pas synchro avec, et ça donne l'impression que c'est la caméra la fautive. Si tu utilises la physique, alors tes objets vont être bougés dans la FixedUpdate mais ta caméra est rendue dans l'Update. Je suis à peu près certain qu'il y a des solutions, mais je n'en ai plus en tête, là de suite, je refouillerai dans mes vieux projets si personne ne sait te dire.
(Note que mon explication est potentiellement foireuse, mais je suis à moitié endormi, là de suite ^^')

----------


## Louck

Il y a de ca, mais c'est aussi un peu plus subtil.

Tout d'abord, l'idéal pour la caméra, est de faire son déplacement dans le LateUpdate (qui est exécuté après tous les updates des composants, et après tous les tests physiques, juste avant la génération de la frame).

Ensuite, comme dit au dessus, il faut s'assurer que l'objet, que suit la caméra, se déplace bien de façon monotone: si dans une frame il se déplace de 10 pixels, alors que dans une autre il ne bouge que de 8 (ce qui peut se produire avec la physique du moteur), ca va créer une saccade au niveau de la caméra. Sinon il faut utiliser le Lerp pour éviter le saccade, pour "fluidifier" le mouvement.


D'ailleurs, tu as fais une erreur:



> transform.position = Vector3.Lerp(transform.position, target, 1);


Ca équivaut à dire :



> transform.position = target;


Car tu as fixé l'interpolant T à 1.

Essayes quelque chose comme ca, plutôt:



> transform.position = Vector3.Lerp(transform.position, target, Time.deltaTime * POWER);


Où "POWER" définit si le Lerp doit être rapide (avec une grosse valeur) ou lent (avec une petite valeur, strictement supérieur à 0).

----------


## saroumana

En fait, j'avais deja appliqué le Time.DeltaTime sur la target avec 



> target = transform.position + new Vector3(Input.GetAxisRaw("Horizontal") * speed * Time.deltaTime, Input.GetAxisRaw("Vertical") * speed * Time.deltaTime, 0);


J'ai tenté en rajoutant deltatime * speed sur le *lerp* / *movetoward*. Faut augmenter la valeur de speed pour que le déplacement se fasse a la même vitesse, mais pareil. Ça avance presque de manière fluide puis ça saccade un coup. Presque toutes les secondes. J'ai vérifié avec process explorer mais j'ai rien qui sature le cpu.




> J'ai déjà eu des soucis du genre. Est-ce que tu utilises la physique dans ton jeu ? Parfois le déplacement de la caméra en lui-même est clean, mais le déplacement d'objets dans le jeu n'est pas synchro avec, et ça donne l'impression que c'est la caméra la fautive. Si tu utilises la physique, alors tes objets vont être bougés dans la FixedUpdate mais ta caméra est rendue dans l'Update. Je suis à peu près certain qu'il y a des solutions, mais je n'en ai plus en tête, là de suite, je refouillerai dans mes vieux projets si personne ne sait te dire.
> (Note que mon explication est potentiellement foireuse, mais je suis à moitié endormi, là de suite ^^')


non c'est très clair.  :;): 
Je fais que tester un peu unity pour voir son potentiel. Et dans la scène, il n'y a que 100*100 sprites qui ne bougent pas. Seul la camera se déplace. Il n'y a rien d'autre, ni aucun script hors camera et génération des sprites au départ.

----------


## Grhyll

Ah ben punaise, avec une scène aussi simple je vois pas bien ce qu'il peut se passer :/ Tu peux éventuellement aller checker dans le Profiler si tu n'as pas des pics, mais je vois pas ce qui pourrait les provoquer sans script dans la scène...

----------


## saroumana

J'ai regardé avec le profiler et rajouté un compteur FPS. Niveau fps je suis constamment a 59fps. Le profiler ressemble a un oscilloscope pour la mémoire même lorsqu'il se passe rien. Le son bouge légèrement alors qu'il en a pas. Pour la section graphique, il a des pics mais vers un frame plus rapide, ce qui devrait normalement ne pas affecter le scrolling.
Le mystère reste donc entier.

----------

