Unity 2D : Les pièges à éviter...

**Ashley TOUCRU** · 04/06/2016, 13h08

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 ?

Donc ça veut dire qu'il vaut mieux utiliser transform.translate pour éviter d'utiliser systématiquement des rigidbody ?

Vous avez des habitudes particulières, vous, pour ce genre de choses ?

**Grosnours** · 04/06/2016, 16h05

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** · 06/06/2016, 13h13

Envoyé par 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.

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** · 06/06/2016, 16h48

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.

**Grhyll** · 13/06/2016, 16h59

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

**Hyperpenguin** · 13/06/2016, 20h37

Aw yeah le tile map, cool!

**Louck** · 14/06/2016, 11h24

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

Tile Map

Dommage que ca arrive tardivement

.

**Grhyll** · 14/06/2016, 16h03

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

**Metalink** · 14/06/2016, 18h39

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

**Grhyll** · 14/06/2016, 20h08

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** · 15/06/2016, 08h36

Envoyé par Metalink

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 ?

**Louck** · 15/06/2016, 10h05

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** · 15/06/2016, 10h50

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

**Ashley TOUCRU** · 15/06/2016, 14h20

Envoyé par 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

.

Ah OK, merci pour l'explication.

- - - Mise à jour - - -

Envoyé par Grosnours

Ç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** · 07/09/2016, 21h05

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.

) : 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 !

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.

**Poussin Joyeux** · 08/09/2016, 21h06

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

**Ashley TOUCRU** · 09/09/2016, 08h12

Envoyé par 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

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 ?

**Longwelwind** · 09/09/2016, 10h46

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** · 09/09/2016, 13h54

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** · 09/09/2016, 14h26

Envoyé par 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

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** · 09/09/2016, 17h52

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.

**Grhyll** · 09/09/2016, 18h10

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** · 09/09/2016, 18h33

Envoyé par 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 !

Ouais, bien sûr que ça m'intéresse.

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 ?

**Longwelwind** · 09/09/2016, 20h51

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** · 09/09/2016, 21h03

Envoyé par 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.

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.

**Hyperpenguin** · 09/09/2016, 23h01

Un dictionnary c'est un tableau en mieux tkt.

**Grhyll** · 10/09/2016, 14h46

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 :

Code:

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** · 12/09/2016, 08h27

Envoyé par Grhyll

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** · 05/11/2016, 17h46

Salut les amis !

Je reviens à la charge !

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 ?

**Grhyll** · 05/11/2016, 18h50

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 !

Discussion: Unity 2D : Les pièges à éviter...

Outils de la discussion

Règles de messages