Organiser ses scripts

[Auronake]

Bonjour à tous,

Débutant sur Unity, je m'interroge sur la "meilleure" façon d'organiser ses scripts.

Plus précisément, je m'atèle, pour commencer, à gérer une caméra et ses différents déplacements me basant sur un gameplay de jeu style Civilization avec les fonctionnalités suivantes :
- Centrage de la caméra sur un GameObject taggué suite à un clic gauche
- Déplacement par flèche/zqsd
- Déplacement par les bords de l'écran
- Déplacement par "drag" du sol par maintient de la molette
- Zoom "en courbe" (de haut, on voit le sol et plus on se rapproche plus on pivote vers l'horizon pour rester à genre 1 mètre du sol)
- Pivotement autour du centre de l'écran par maintient du clic droite ou touches ae

La caméra est en perspective et orienté vers le sol à 90°

J'ai créé deux scripts : InputManager (Attaché à un GO vide et qui possède une référence vers la caméra) et CameraMovement (attaché à la caméra).

Dans l'idée, l'InputManager sert à récupérer tous les inputs de clavier et de souris (et pas seulement ceux de la caméra mais n'importe lesquels). En fonction, j'appelle des méthodes public du script CameraMovement de la caméra.

Déjà 1ère question: je me demande si cela a un intérêt de faire ça ? Ne serait-il pas mieux/plus facile de mettre les inputs servant à la caméra directement dans le script CameraMovement ?

Ensuite, en cherchant sur le net, j'ai vu/lu le modèle de conception "Entity Component Engine". A vrai dire, je n'ai pas tout compris encore, ni assez d'expérience pour comprendre l'intérêt mais voici ma seconde question :

Serait-il intéressant (bonne pratique) de faire un script par fonctionnalité décrite ci-dessus et ainsi avoir un script CentrageCamera, DeplacementCamera, etc ? Ou bien est-ce usuel que le script CameraMovement contienne toutes les fonctions liées au mouvement ?

En espérant avoir été assez clair sur mes attentes!

Merci par avance

[minirop]

pour info, Unity utilise déjà un système d'entités (les gameObject) et de composants (les choses que tu attaches à tes GO comme les scripts, les renderers, etc.)

Pour ta question sur le script, ça dépend (de tous les facteurs possibles et imaginables). Mais pour reprendre ton exemple, tu pourrais avoir :
- un script qui centre la caméra qui un point (qui peut bouger, comme un NPC)
- un autre script qui bouge un GO suite à l'appui sur les touches du clavier (et le script précédent centrerait la caméra sur ce GO)

[Auronake]

Pour Unity et sa gestion Entité/Composant, c'est bien ce qu'il me semblait, ça ressemblait déjà à ce que j'ai lu, d'où le fait que je me pose la question du découpage par "fonctionnalité" comme ça une caméra peut acquérir différentes fonctionnalités que je possèderai unitairement...

Je pense que je vais partir là dessus pour tester si c'est embêtant ou non à la longue.

Par contre, concernant la séparation entre input et fonctionnalité, est-ce judicieux ou bien l'on peut considérer que pour "bouger" , il faut un input et donc l'ajouter à la dite fonctionnalité ?

Je me pose cela notamment pour la configuration des touches par le joueur (ça reste hypothétique encore mais bon ^^), est-ce qu'il sera compliqué de faire matcher les nouvelles touches avec celles qu'on gérait avant ? Mais à la réflexion, on nomme les inputs et on se base sur ce nom il me semble, donc cela ne devrait pas poser de souci...

Désolé, j'écris au fur et à mesure que je pense donc bon

[minirop]

tu fais ce que tu veux en fonction de découplage que tu veux, par exemple :

• Tu ne permets pas le changement des touches.
• Tu utilises le launcher Unity et donc son input system : GetButtonDown("Fire")
• Tu fais un système perso avec une classe qui contient le lien entre la touche et le type d'action : GetKeyDown(MonInput.Sauter) <-- voire code plus bas.
• Tu peux séparer encore plus en extrayant le "GetKeyDown(...)" dans une autre classe et ton composant Caméra appellera "if (blablabla.BougeVersLaDroite())" (qui elle appelle GetKeyDown()).

Code : Tout sélectionner

class MonInput
{
	// initialisation aux valeurs par défaut
	public static KeyCode Sauter = KeyCode.Space;
	public static KeyCode Taper = KeyCode.Enter;
	public static KeyCode Gauche = KeyCode.LeftArrow;
	public static KeyCode Droite = KeyCode.RightArrow;
	// etc.
	
	void Awake()
	{
		// lecture dans un fichier de configuration les valeurs enregistrée
		// par le joueur dans le menu de configuration du jeu.
		// ...
	}
}

[Auronake]

Ok, merci pour la précision

Je pense que dans un premier temps, je vais faire avec la solution 2 pour simplifier, je verrai par la pratique si ça va poser problème ou pas