Skip to main content

Unity WebGL et communication avec le Web

Vue d’ensemble

Le jeu Unity WebGL est intégré au Website Angular et communique avec le backend NestJSNestJS. pourCette récupérerpage ouprésente enregistrerles plusieursresponsabilités donnéesde métier.chaque couche et les principaux points à vérifier lorsqu’une modification touche le jeu et le Web.

Architecture générale

flowchart LR
    USER[Utilisateur] --> ANG[Angular / PageWebgl]
    ANG --> BUILD[Build Unity WebGL]
    BUILD --> UNITY[Runtime Unity]

    UNITY -->|HTTP| GAME[GameController]
    GAME --> GS[GameService]

    GS --> BC[BrainCloud]
    GS --> REDIS[(Redis)]
    GS --> STORAGE[storage / images / logs]

    ANG -->|Auth / session / navigation| NEST[NestJS]
    NEST --> ANG

Côté Angular

PageWebglComponent est utilisél’écran qui héberge le jeu pour plusieurs routesroutes, de jeu :notamment /game, /demo, /alpha, /alpha2 et /demoLive.

Le build Unity est livré dans les assets frontend. Le frontend Angular gère le contexte Web autour du jeu : navigation, authentification, chargement et communication avec les autres fonctions du site.

Côté backend

GameController dans uniksim-back-end/src/app.controller.ts est protégé par AuthGuardGame. etIl exposedélègue la logique à GameService.

Les endpoints couvrent notamment :

  • version du build ;build;
  • informations de code produit ;produit;
  • textes et traductions ;traductions;
  • écoles ;écoles;
  • token Web ;Web;
  • heartbeat ;et présence en jeu;
  • classements ;classements;
  • images utilisateur ;utilisateur;
  • journalisation de crash.

FichiersFlux heartbeat

sequenceDiagram
    participant U as Unity WebGL
    participant G as GameController
    participant S as GameService / server.js
    participant R as Redis

    U->>G: heartBeat(simUid, userUid, token)
    G->>S: heartBeat(...)
    S->>R: Vérifie session / présence
    R-->>S: État session
    S->>R: Met à jour présence + expiration
    S-->>G: Version / heartbeats / sessionTime
    G-->>U: Réponse

Build et fichiers statiques

Le backend utilise ServeStaticModule pour servir le frontend compilé depuis dist/front. Les assets Unity WebGLfont sontpartie intégrésdu aufrontend frontend.Angular. Le build Angular de production est ensuite généré dans uniksim-back-end/src/front, puis servi par NestJS avec ServeStaticModule.

Voir Build et déploiement Web pour l’ordre complet de build.

RègleQuand modifier plusieurs projets

Une modification du contrat Unity/Web nécessite souvent de maintenancevérifier plusieurs couches :

flowchart LR
    CHANGE[Changement Unity / Web] --> UNITY[Code Unity]
    CHANGE --> ANG[Angular / PageWebgl]
    CHANGE --> API[GameController]
    API --> SERVICE[GameService]
    SERVICE --> DATA[BrainCloud / Redis / stockage]

    UNITY --> TEST[Test WebGL]
    ANG --> TEST
    API --> TEST

Fichiers à connaître

Lorsqu’un

changementuniksimFrontEnd/src/app/Pages/PageWebgl/ toucheuniksimFrontEnd/src/assets/unity/ uniksim-back-end/src/app.controller.ts — GameController uniksim-back-end/src/service/game.service.ts uniksim-back-end/src/guards/authGame.guard.ts uniksim-back-end/src/node.js/server/server.js uniksim-back-end/src/node.js/server/backend_braincloud.js

Points d’attention

    Ne pas modifier seulement le frontend si le format attendu par Unity ou l’API change. Vérifier le guard et le Web,contexte toujoursd’instance documenter(live/dev/demo) pour les deux côtésendpoints du contratjeu. :Les leheartbeats codeont Unitydes quieffets envoiesur ouRedis reçoitet la présence; les donnéestraiter etcomme l’endpoint/serviceun NestJSflux correspondant.runtime important. Après un nouveau build Unity, vérifier que les nouveaux fichiers WebGL sont bien ceux inclus dans les assets/build déployés.
    Back to top