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.

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.

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 ?

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. 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.

- - - 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 ! 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.

[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
- 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.

Carrément ! 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. Challenge ! J'aime.

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 !

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. 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

[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. Or j'ai bien compris que c'était le cœur du programme. 'Va falloir s'accrocher !

[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. 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 ? Qu'entends-tu par "des assets pixel perfect" ?

[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
(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…

- - - 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 ?

[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...

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.

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.

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

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.

[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 ?
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.

[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.

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]

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 ?

[Grosnours]

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

[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 !