Bjr,

Je fais un script pour conduire une voiture : https://pastebin.com/0uJgPgiG
Qui peut me donner son avis.

je pense refaire le script et prendre celui la : https://www.youtube.com/watch?v=cqATTzJmFDY

Qui peut me donner son avis.

Le script est pas mal, mais voici quelques détails si tu veux des axes d'amélioration :

- tu peux rajouter un header [RequireComponent(typeof(Rigidbody))]à la classe pour ne pas te prendre d'erreur sur le GetComponent du awake

- tu peux créer un Scriptable Object pour y mettre tous les paramètres (speedmax, etc.)

- tu peux mettre des Else if sur tes évaluations de forward amount pour éviter des évaluation inutiles de if qui seront toujours faux (et faciliter la lecture)

- tu peux factoriser les formules de calcul pour ne pas les répéter X fois (et donc avoir des risques d'erreurs en cas de changement, et également alléger la lecture)

- tu peux utiliser la fonction collision.gameObject.CompareTag("Zombie") à la place de collision.gameObject.tag == "Zombie" pour un gain de 28% de performance

- tu fais plusieurs fois dans la même fonction collision.gameObject.GetComponent<Zombie>() , tu peux le stocker, GetComponent est assez couteux

- tu peux utiliser la fonction collision.gameObject.CompareTag("Zombie") à la place de collision.gameObject.tag == "Zombie" pour un gain de 28% de performance

Ah bon ?

- tu fais plusieurs fois dans la même fonction collision.gameObject.GetComponent<Zombie>() , tu peux le stocker, GetComponent est assez couteux

Stocker comment ?

- tu peux factoriser les formules de calcul pour ne pas les répéter X fois (et donc avoir des risques d'erreurs en cas de changement, et également alléger la lecture)

Je ne vois pas comme quoi ?

Le script est plutôt bien fait.

Rien à redire sur les conseils de IndepGameDev j'aurais fait les mêmes.

Sur la ligne :

if (collision.gameObject.tag == "Zombie" && collision.gameObject.GetComponent<Zombie>().isDead == false){ ... }

Tu ne vérifie pas l'existence du MonoBehaviour "Zombie" donc tu auras une erreur si un objet taggé "Zombie" n'a pas ce monobehaviour.
De plus je trouve redondant d'avoir un tag et un monobehaviour pour faire la même chose. C'est un coup à oublier le tag quand on créé un objet.
Du coup je virerais le tag et remplacerais par :

MonoBehaviour Zombie =  collision.gameObject.GetComponent<Zombie>();
if (Zombie && !Zombie.isDead){ ... }

De plus je pense que ce bout de code aurait plus sa place dans la classe Zombie que dans la classe CarDriver.

Ah bon ?

C'est un détail pour ton usage, mais oui, le compareTag évite de l'allocation mémoire et est donc plus rapide. C'est cité ici par unity (si tu cherches tag dans la page) https://learn.unity.com/tutorial/fixing-performance-problems#5c7f8528edbc2a002053b595

Stocker comment ?

Juste comme ça, mais pareil c'est un détail mais prendre de bon reflexe c'est toujours bien
https://pastebin.com/898JUFd1

D'ailleurs ta fonction zombi.IsHit() est étrange, vu son nom tu devrais récupérer un boolen, si c'est pour que le zombi prenne en compte le hit, ce n'est pas le bon nommage

Je ne vois pas comme quoi ?

L'idée est de ne pas répéter X fois la même formule mathématique, tu peux créer une simple méthode qui fait forwardAmount * _PARAMETER_ * deltaTime par exemple. Si tu dois modifier cette formule tu ne le fais qu'à un endroit et donc tu évite d'oublier

C'est ça mon scripts Zombie
https://hatebin.com/jziudmuzef

Le Is c'est plutôt pour tout ce qui retourne un booleen et qui ne fait pas vraiment de traitement.

Là tu prends en compte un hit, donc le bon nommage c'est plutôt "ProcessHit()", "HandleHit()" ou quelque chose du genre.
Sinon pourquoi pas un peu en mode évènement aussi avec un participe passé comme "Hitted()"

https://docs.microsoft.com/en-us/dotnet/standard/design-guidelines/names-of-type-members?redirectedfrom=MSDN

Sinon pourquoi pas un peu en mode évènement aussi avec un participe passé comme "Hitted()"

hit est irrégulier! ;)
Mais oui, juste Hit() c'est mieux IsHit (qui effectivement se lirait Is hit? donc retournerait un booléen).

C'est un détail pour ton usage, mais oui, le compareTag évite de l'allocation mémoire et est donc plus rapide. C'est cité ici par unity (si tu cherches tag dans la page) https://learn.unity.com/tutorial/fixing-performance-problems#5c7f8528edbc2a002053b595

Je suis sur le cul en lisant ca (le lien). Et c'est pas forcément le sujet pour en discuter, mais comme quoi, on ne facilite pas vraiment les choses "en ne gérant pas la mémoire".

Le 25 mars 2021 à 17:02:00 Guybrush81 a écrit :

Sinon pourquoi pas un peu en mode évènement aussi avec un participe passé comme "Hitted()"

hit est irrégulier! ;)
Mais oui, juste Hit() c'est mieux IsHit (qui effectivement se lirait Is hit? donc retournerait un booléen).

Ca me fait mal au cœur de ne pas connaitre mes verbes irrégulier

C'est un détail pour ton usage, mais oui, le compareTag évite de l'allocation mémoire et est donc plus rapide. C'est cité ici par unity (si tu cherches tag dans la page) https://learn.unity.com/tutorial/fixing-performance-problems#5c7f8528edbc2a002053b595

Je suis sur le cul en lisant ca (le lien). Et c'est pas forcément le sujet pour en discuter, mais comme quoi, on ne facilite pas vraiment les choses "en ne gérant pas la mémoire".

On facilite les choses, mais rien n'est magique. On facilite parce qu'il n'y a pas de problème de mémoire par défaut, mais il faut savoir comment les choses fonctionnent pour optimiser la mémoire.

Après je sais pas c'est quoi le mieux velocity ou addForce ?

Le 25 mars 2021 à 18:15:21 PillsDispenser a écrit :
Après je sais pas c'est quoi le mieux velocity ou addForce ?

C'est à toi de voir comment tu veux que se comporte la / les voitures, etc...

Je pense que addForce est plus juste ici, mais c'est un petit peu plus compliqué d'avoir les bons réglages.

Si je ne dis pas de connerie, le fait de modifier la vélocité va mettre le rigidbody à la vélocité souhaitée mais ne prend pas en compte la masse, etc. Le addForce prend en compte la masse et autre pour déterminer la vélocité.

En gros si tu as une voiture de 1 tonne et une de 200 kg avec le même moteur, changer la vélocité va donner la même vitesse aux 2 voitures à frame où tu l'applique, mais pas si tu fais addForce (celle d'une tonne ira moins vite).

Ca me fait mal au cœur de ne pas connaitre mes verbes irrégulier

Je ne les connais pas très bien non plus, et j'aurai pu écrire "hitted", mais en le lisant ca m'a semblé étrange ;)

On facilite les choses, mais rien n'est magique. On facilite parce qu'il n'y a pas de problème de mémoire par défaut, mais il faut savoir comment les choses fonctionnent pour optimiser la mémoire.

C'est justement ce revers de la médaille que je trouve questionnable dans les langages "sans gestion de mémoire" (ce que j'ai souvent rencontré en Objective-C/Swift par exemple), c'est que ca apporte de "nouveaux" problèmes (en C++ on aurait un seul accesseur pour le tag, qui ne ferait aucune allocation).

Si je ne dis pas de connerie, le fait de modifier la vélocité va mettre le rigidbody à la vélocité souhaitée mais ne prend pas en compte la masse, etc. Le addForce prend en compte la masse et autre pour déterminer la vélocité.

Oui c'est ca, en appliquant une force, celle ci sera divisé par 1/m (ou 1/I dans le cas d'un torque autour d'un axe) pour calculé l’accélération avant d'intégrer la vitesse.

Dans fixed update il faudrait pas mettre uniquement le déplacement de la physique ?
Et les calcules et les inputs dans update ?

J'ai suivi la vidéo que j'ai mise en titre du coup le script donne ca : https://pastebin.com/GkxeBRr5

Par ailleurs c'est quoi la différence sur la rotation entre :

transform.rotation = Quaternion.Euler(transform.rotation.eulerAngles + new Vector3(0f, turnInput * turnStrength * Time.deltaTime * Input.GetAxis("Vertical"), 0f));

carRigidbody.angularVelocity = new Vector3(0, turnSpeed * (invertSpeedNormalized * 1f) * Mathf.Deg2Rad, 0);