Fonction Update

[fiercy]

Bonjour,

Petite question autour de la fonction Update();
Mon fiston est en train de suivre les tuto de kriss et se fait donc un petit RPG. Comme il commence en JS, il copie le code puis le bidouille pour découvrir.
Hier il a fait un truc que je trouve bizarre de mon point de vue de "vieux dév proche de la machine", mais qui est sans doute assez logique.
La fonction update() est une fonction de boucle d'événement et dans cette fonction, il a mis le code qui teste si Fire1 a été appuyé. Cela entraine le tir. Puis comme il voulait deux armes, il a dupliqué le script et dans le second il a testé Fire2, a réglé l'arme différemment, le son etc.

Il a donc, dans son jeu, deux fois la fonction update() ce qui visiblement ne pose pas de problème: quand il tire avec le bouton droit il a une arme, et avec le bouton gauche une autre arme.

Personnellement, j'aurais fait une seule routine et des tests.

J'aimerais avoir votre avis la dessus: préférez-vous avoir une routine et des tests (comme nous faisons avec nos gestion d'Event sur Atari, Mac...) ou bien préférez-vous avoir un script par type d'Event donc plein de routine update()? En terme de performance, est-ce que ça fait une différence?

D'avance merci pour vos réponses
Amitiés
PL

[Loulou]

Je vais essayer d'expliquer comment tout ca marche.

Tout les éléments de la scène sont des GameObject, chaque GameObject peut avoir un ou plusieurs Component. De base tout GameObject a un Component Transform qui permet de spécifier sa position, sa rotation et son scale dans la scène. Il est possible de rajouter d'autre Component comme MeshFilter, MeshRenderer, CapsuleCollider, ParticuleEmitter ... Tout element rajouté a un GameObject est un Component. Par déductions les Script sont donc des Component.

Dans le coeur de Unity comment ca marche ? En algo simplifié ca donne ca :

Code : Tout sélectionner

tant que l'application n'a pas quitté
	
	//Debut de l'execution d'une boucle de jeu
	
	pour tous les GameObject actif de la scene courant
		pour tous les Component actif du GameObject
			Update() //et d'autre fonctions bien sur mais la c'est Update qui nous interesse
		fin pour
	fin pour
	
	//Suite de l'execution d'une boucle de jeu
	
fin tant que

Au début de l’exécution de la boucle il peut y avoir la mise a jour de la classe Time, la mise a jour de la classe Input ... dans la suite de l’exécution il peut y avoir l'affichage, la synchro réseau ... mais tout ca est gentillement géré par Unity (vive les middleware \o/)

Il n'est pas gênant de mettre plusieurs Script sur un même GameObject, avec pour chacun s propre fonction Update. Chaque Update sera appelé l'un après l'autre et la "perte" de performance est ... inexistante . Il est par contre important de rassemble son code par fonctionnalité.

Exemple, un script peut gérer les armes du personnage avec les différent teste sur Input (Fire1, Fire2 ...)
Et un autre peut gérer les dégâts du personnage avec une fonction ApplyDommage (appelé par un autre script de la scène).

De cette façon le même second script peut très bien aussi servir sur les GameObject ennemie de la scène par exemple (ou tout objet destructible ayant des points de vie). Le but étant de minimiser au maximum la duplication de code.

Voila j’espère ne pas t'avoir plus embrouillé qu'autre chose (maintenant que je me relis ça fait long comme post)

[fiercy]

Il n'est pas gênant de mettre plusieurs Script sur un même GameObject, avec pour chacun s propre fonction Update. Chaque Update sera appelé l'un après l'autre et la "perte" de performance est ... inexistante . Il est par contre important de rassemble son code par fonctionnalité.

Si la perte de performance est minime avec les appels successifs de Update, donc si en fin de compte au lieu d'avoir une boucle avec un event, d'avoir une boucle qui appel plein d'event, je vois pas en quoi il serait important de grouper par fonctionnalité.
Par soucis de clarté de code? là je suis d'acord.

Amitiés
PL

[giyomuSan]

Le tric avec unity c de penser code reutilisable et component.

Donc dans le cas de ton fiston, il devrais creer un seul et meme script, exposer un variable pour le type de bouton, fire 1 ou 2 etc..

De la gerer le tir de maniere generic.

A partir de la tu utilise ce script autant de fois que tu veux sur les objets correspondant.

[fiercy]

Le tric avec unity c de penser code reutilisable et component.

Donc dans le cas de ton fiston, il devrais creer un seul et meme script, exposer un variable pour le type de bouton, fire 1 ou 2 etc..

De la gerer le tir de maniere generic.

A partir de la tu utilise ce script autant de fois que tu veux sur les objets correspondant.

OK; ce qui reste sans doute un peu troublant c'est le fait qu'on a un système d'outil "mono" donc un "logiciel" qui utilise un concept de langage prévu à la base pour du multi-page. En C par exemple, impossible d'avoir plusieurs exemplaires d'une même fonction puisque tout le code est dans le même bloc, une fois compilé.

En même temps, ce concept "multi page" est sans doute plus sympa pour débuter, puisqu'il permet pas mal de petits essais sans se prendre la tête. En tout cas, c'est ce que que je constate quand je vois mon fils taper du code. Reste que si personne n'est sur le dos du débutant, il a vite fait de pondre des trucs infames et quand il verra surgir les problèmes, ce sera bien tard.

En tout cas, merci beaucoup pour vos réponses
Amitiés
PL