Salut,

Je ne suis pas forcément spécialiste sur Unity (je suis dessus depuis plus de 6 mois maintenant, avec quelques années de programmation avant ça), mais je veux bien y jeter un œil.

Je te laisse mon adresse mail pour m'envoyer le projet, je la supprimerai une fois que tu auras répondu pour ne pas me faire spammer par un bot.

Ok, je regarde ça cette aprem ou demain. Je posterai ici la "critique" du code, comme ça tout le monde pourrait en profiter et donner son avis. (et je t'enverrai un mail en même temps pour te dire que j'ai répondu sur le forum)

J'ai regardé un peu ton code. Il y a certaines choses avec lesquels je ne suis pas personnellement encore à l'aise (les coroutines par exemple), donc je n'en parlerai pas.

Sinon, il y a peut être deux trois choses sur lesquels je peux revenir.

Dans les scripts CameraScript.cs et Client.cs, tu as des variables déclarées comme static. Ça ne serait pas plutôt des constantes que tu aurais voulu mettre à la place?
(public static float STANDARD_WIDTH = 1920.0f; => public const float STANDARD_WIDTH = 1920.0f; par exemple)
Le fait de les mettre en static va juste faire en sorte qu'elles seront accessibles partout même si la classe n'est pas instanciée, mais ici, obligatoirement, le script sera instancié vu qu'il est "accroché" sur la main camera.
Si tu les mets en constante, il ne pourront plus changé de valeur et ne sera pas accessible via d'autres scripts, mais ça ne prendra pas de place en mémoire (à la compilation du code, partout où le compilateur tombe sur STANDARD_WIDTH, ceci sera remplacé directement par la valeur déclarée au début du script.

En parlant de la main camera, c'est normal que tu en ais deux (une camera comme child de Main Camera)? (Si oui, je n'ai pas su comprendre exactement pourquoi en lisant ton code)

Pour Block.cs, les différentes variables de type Block, ça pourrait être plus intéressant de les mettre dans un tableau. Block [] voisins; par exemple, en mettant en commentaire sur le dessus que 0 = voisin de gauche, 1 = voisin de droite, etc. Ça serait utile dans le cas où tu devrais les manipuler les unes après les autres dans une boucle. Dans le code du jeu sur lequel je travaille pour le moment, j'ai un "schéma" plus ou moins semblable au tien dans le sens où un GameObject a pour component un script qui contient une liste de ses voisins (celui en haut à gauche (voisin[0]), celui en haut (voisin[1]), celui en haut à droite (voisin[2]), celui à droite (voisin[3]), etc.), et le fait d'avoir l'ensemble de ses voisins dans un unique tableau, rend les choses plus facile à manipuler et plus clair dans le code je trouve.

Pour InteractionScript.cs, apparemment, c'est recommandé de traiter tout ce qui est physics dans un FixedUpdate () plutôt que dans un Update () (It's for this reason that FixedUpdate should be used when applying forces, torques, or other physics-related functions - because you know it will be executed exactly in sync with the physics engine itself.). Donc dans Update, quand on click sur un bouton de la souris, tu peux activer un bool du style isMouseZeroDown.; et dans FixedUpdate (), quand isMouseZeroDown == True, lancer le rayon et faire le traitement. A la fin du traitement, passer isMouseZeroDown à False.

De façon général, mettre en haut de chaque classes un gros commentaire avec le but de cette classe et à quoi elle sert, voir comment elle interagis avec d'autres classes si c'est le cas. Personnellement, j'ai toujours du mal à me forcer à mettre des commentaires parce que je suis pressé de mettre en place ma logique et de sortir ce que j'ai en tête, mais quand il faut replonger dans le code, ça sera beaucoup plus facile.

Voilà en gros ce que je modifierai, tout en sachant que ça ne fait que 6 mois que je suis sur Unity (avec deux ans de programmation avant cela), donc, peut être que pour certains points, certaines personnes te diront le contraire (je ne pense pas, mais je peux me tromper :p). De plus, comme j'ai dit plus haut, pour ce qui est coroutine, je ne suis pas capable de te dire si tu as bien codé tout ça. Il faudrait un second avis un peu plus expert.

Sinon, dés que tu as finis, n'hésite pas à poster le jeu sur le forum et si tu veux que je rejette un coup d’œil d'ici un certain temps, n'hésite pas non plus. Je ne suis pas un expert, mais c'est toujours utile d'avoir un second avis sur son code.