Discussion :

[uinet_propane]

Bonjour à tous,

je suis nouveau ici (enfin c'est mon premier post).
Je suis informaticien spécialisé en système et réseau.
Et développeur amateur à mes heures perdues.

Actuellement je développe un jeu 3D qui si je vous le décrit va me faire passé pour un doux dingue ... donc pour faire simple c'est un MMO persistant.
Ce que je peux vous dire en 2 mots, c'est que l'infra matériel et logiciel existe déjà (sous forme d'un datacenter virtualisé reposant sur 3 serveur PowerEdge 2950. Du pro quoi). Et niveau compétence, en codage je pense maîtriser assez le C# pour m'attaquer a ce genre de projet.
Je vous passe les détails du scénario et de l'univers pour en venir à ma question.

Contexte :
1. J'ai un client en Unity3D qui fonctionne bien au niveau gameplay.
2. J'ai un service Windows qui fait office de serveur de jeu, que j'ai créé pour être modulaire. Comme ce serveur est sensé tourner 24/24 7/7, j'ai tout de suite tenu compte des problèmes de performances, de charge et les éventuelles pannes coté serveur. J'ai donc décidé de faire reposer mon "serveur de jeu" sur un ensemble de MJ (maître de jeu) indépendants pour pouvoir gérer tout ça. Chaque MJ a ses propres thread et est gérer par le service. Le service peut instancier différents MJ. Actuellement phase de developpement, le serveur instancie tous les MJs. Mais au final normalement chaque MJ sera herbergé sur un serveur différent ('est le meme exe, simplement démarrer avec des options différentes).

L'infrastructure coté serveur se découpe donc comme suit :
Une DB SQL hébergée sur un serveur Windows en interne (LAN)
Un service codé en C#, multithread, multiclient, qui implémente plusieurs MJ, et en particulier des MJ que j'appel MJSysteme et qui gère les différentes zones jouable du jeu.

Voilà a quoi ressemble mon serveur


Mon problème c'est de savoir au niveau conceptuel comment instancier les zones jouable coté serveur.
Les joueurs vont entré en jeu en se connectant a un MJSystème qui leur est attribué. Ce MJSysteme doit pouvoir gérer l'environnement du jeu comme un joueur. Donc il va devoir faire plein d'opérations 3D. Ma question est donc de savoir comment instancier ces zones jouables coté serveur, sans trop impacter les performances, en tenant compte que coté serveur c'est pas une machine de jeux avec une carte graphique de ouf, mais une machine virtuelle hébergée sur un serveur professionnel haute performance. Donc niveau graphique faut pas compter sur un GPU. Par contre CPU et RAM y en a à revendre

Question :
Est-ce qu'il faut que je charge la scène Unity pour simuler coté serveur tout ce qui se passe dans la scène aux niveaux des joueurs et "bénéficier" des fonctions de Unity, comme les collisions, pour valider les actions de mes joueurs ?
Est-ce que la scène Unity peut être utilisé sans camera, sans représentation visuel et sans GPU ?
Ou vaudrait-il mieux recréer les environnement jouable dans une forme spécifique coté serveur ? Mais alors comment gérer la partie "3D" sans faire appel a Unity3D (recréer un moteur 3D coté serveur) ?

Tout remarque, suggestion ou idée me permettant de déterminer comment gérer mes zones jouables coté serveur est bienvenue.

[uinet_propane]

Pour préciser un peu, comment coté serveur puis-je faire pour valider les actions dans l’environnent coté client géré par Unity ?

Typiquement coté serveur, comment valider un déplacement en tenant comptes des possibles collisions entre le joueur et l'environnement.

Coté client c'est le moteur de Unity qui s'en charge.
Mais je veux pas compter sur le client pour valider le déplacement.
Il faut que je confirme coté serveur qu'il n'y a pas de collision et que le déplacement est légal.

A priori la solution la plus judicieuse serait de charger la scène correspondante coté serveur et de vérifier dans la scène que le déplacement demandé est valide.
Mais ça implique que Unity tourne coté serveur. Et c'est sur cet aspect que ma question (moteur Unity coté serveur)

[Bousk]

Il faut charger la scène sur le serveur si tu veux l'utiliser.
L'abscence de carte graphique n'impacte que l'affichage que tu ne fais pas. Le reste sont des données en RAM (navmesh, positions, ...).
J'ôse espérer que ceci est possible sur Unity (sinon c'est une sacrée lacune..) mais je n'en ai aucune idée.
Pour la caméra, à nouveau son abscence ne devrait rien y changer. Au pire tu peux voir ça comme une caméra libre.

[uinet_propane]

Il faut charger la scène sur le serveur si tu veux l'utiliser.

Me semblait bien qu'il faut que je fasse ca.

J'ôse espérer que ceci est possible sur Unity (sinon c'est une sacrée lacune..) mais je n'en ai aucune idée.

C'est précisément ce que je cherche à déterminer. Si c'est possible, et si oui comment faire

A priori ca doit être possible, mais j'ai pas trouvé d'info clair ni de tuto. Donc actuellement je fais des testes en rajoutant les libraire de Unity dans le projet de mon serveur, et je tente de voir si j'arrive a charger la scène de test et à la simuler. Pour le moment c'est pas très réussi, faut que je débogue le chargement coté serveur

[uinet_propane]

Bon après quelque test, je peux déjà affirmer qu'il n'est pas possible de charger une scène dans un exe qui n'a pas été fait dans Unity. L'appel aux fonctions de chargements des scenes (SceneManager.LoadScene()) n'est pas possible en dehors de Unity (ça provoque une erreur d'Ecall) ...

Par contre il semble possible de bidouiller Unity pour le faire tourner comme un service Windows, et limiter la partie graphique. Donc dans mon cas la solution c'est de recoder mon MJSysteme dans Unity, puis de lancer l'exe MJSysteme en mode batch headless (sans fenêtre, sans interaction utilisateur). De cette façon le moteur tourne en arrière plan et en rajoutant ma surcouche "MJ", je devrais pouvoir considérer l'exe Unity comme la composante serveur du jeu.
Heureusement j'avais pas trop avancer sur le MJSysteme vu que j'étais bloqué par cette question du moteur.

Pour l'aspect service, je vais bidouiller avec les outils Windows pour installer l'exe comme service.

[Bousk]

Bien sûr qu'il te faut un server Unity, un build server depuis ton projet.
Vouloir ouvrir une scène Unity avec un exe non créé par unity... tu vas y passer plus de temps qu'autre chose, pour un résultat très incertain et très certainement incorrect.

Ils sont en train de refaire leur couche network mais faut lire la doc, ils expliquent tout.
https://docs.unity3d.com/2019.2/Docu...nual/UNet.html

[uinet_propane]

Vouloir ouvrir une scène Unity avec un exe non créé par unity... tu vas y passer plus de temps qu'autre chose, pour un résultat très incertain et très certainement incorrect.

Dans ma logique et ma compréhension c’était ce qu'il fallait faire. J'avais pas penser au fait de lancer unity sans interface

pour la couche réseau, j'ai vu qu'ils la refaisaient. Et vu qu’ils sont en plein dedans, je choisi de contourner ça en développant ma propre couche réseau reposant sur les librairie .Net.

De tout façon j'ai pas le choix de cette approche vu que j'ai besoin d'un serveur de jeu modulaire, et que certains modules n'ont aucun lien directe avec le moteur de jeu Unity, ils reposent forcément sur les librairie .Net.

Enfin bref, je reviendrai compléter le sujet avec ma solution "serveur Unity" ca pourra toujours être utile à d'autres.

[uinet_propane]

J'ai réussi à adapter mon code pour faire tourner mon MJ dans Unity3D.

Pour ceux que ça intéresse, voilà ce que j'ai fait :
1. J'ai une classe MJSysteme, qui est une classe purement .Net (sans référence ni appel aux fonctions Unity3D).
Cette classe implémente tout ce qui concerne la gestion du MJ et le réseau au niveau de mon jeu (sockets, threads, commandes du protocole).
2. J'ai adapté cette classe pour qu'elle puisse à la fois être instancié dans mon code de test (débogage) ET dans Unity (constructeur spécifique, et une fonction d'initialisation dans Unity3D).
3. Tout ca est distribué sous forme de DLL importé dans mon projet Unity.

4. Dans Unity, j'ai un monoscript lié à un GameObject qui instancie 1 objet MJSysteme de la DLL. J'appel ce script ServeurDataMgr.
5. Le ServeurDataMgr souscrit à un événement particulier du MJ, ce qui permet au MJ de faire appel à un délégué du ServeurDataMgr pour traiter les requêtes/réponses qu'il ne sait pas traiter lui même, sans pour autant devoir connaitre quoi que ce soit au niveau de Unity.

En faisant ça, toute commande réseau qui implique Unity est remonté au niveau de Unity pour être traité par un script, qui peut accéder au MJ. Tout ce qui ne dépend pas de Unity est traité au niveau du MJ, sans que Unity n'en soit informé (sauf exception requise par le jeu). Le MJ a ses propres threads et Unity le sien. Evidemment la partie Unity fait partie du MJ, mais ce sont des classes séparées.

Maintenant faut que je code la partie Unity qui traite les commandes du protocole concernée, mais bon ça c'est une question d'implémenter les actions du protocole, ça ne dépend plus d'une question de compatibilité du code.

Pluton content d'en être arriver là.