Advanced Search
Search Results
86 total results found
Régularisations de fin de période
Rôle Les régularisations transforment les données accumulées pendant le module en écritures de fin de période. Elles concernent notamment amortissements, contrats, stocks et comptes explicitement configurés pour être régularisés. Préférences structurantes Les ...
acc_base, acc1 et acc2 — séparation des responsabilités
Principe La vraie logique Accounting partagée côté serveur vit dans acc_base. acc1 et acc2 sont des wrappers qui instancient la même base avec un GameUid différent et exposent les commandes sous le namespace propre au jeu. Utils classDiagram class GameSpeci...
Architecture By Year
Rôle By Year est le framework historique où une activité progresse année par année. À chaque année, les équipes prennent des décisions game-specific, le serveur génère les résultats, calcule les évaluations et prépare l'année suivante. flowchart LR ACT[Activit...
Modèle de données By Year
Objets Unity SimulationByYear : simulation et options propres à la famille; ActivityByYear : année courante, états, calendrier et données de l'activité; TeamByYear : équipe et données runtime; TeamDecisionsByYear : décisions par année; ResultsByYear : résultat...
Cycle d’une année, calendrier et jobs
startYear() utils_by_year.startYear(actData, updateYearFinished) incrémente l'année si nécessaire, passe l'état à ACT_YEAR_STARTED, enregistre startTime, appelle startYearGameSpec(), initialise les stubs de présence puis envoie act_year_started. stateDiagr...
Décisions et génération des résultats By Year
Principe Le framework By Year ne connaît pas la structure détaillée des décisions. Il délègue à utilsByGameUid[gameUid] et au moteur generateResultsByGameUid[gameUid]. sequenceDiagram participant U as Unity Decisions UI participant B as BackEndBrainCloud par...
Évaluations, logbook, scénarios et rankings By Year
Évaluations _utils/utils_eval.js fournit le cadre commun pour activité, présence, logbook, custom evaluations et stubs. Chaque jeu fournit ensuite son Eval<Game> via la factory d'évaluation. Scores game-specific Les classes EvalEnt1, EvalHr1, EvalMgt1, Ev...
Bots et simulations asynchrones By Year
Quand les bots sont utilisés Dans generateResultsJob(), si actData.isAsync est vrai, takeBotsDecision(actData) est appelé avant la génération des events et résultats. Jeux avec bots explicites Le routeur commun instancie actuellement BotsEnt1, BotsMk1 ou ...
UI et prefabs By Year
Socle commun Assets/Src/UI/SimByYear/ contient l'UI réutilisée par les jeux annuels. Le contenu métier propre à ENT1/HR1/MGT1/MK1/MK2 reste dans Assets/GameSpecific/<gameUid>/Src/UI et leurs prefabs Resources. Contrôles principaux Domaine Classes Simulation s...
ENT1 — architecture et logique game-specific
Positionnement ENT1 est un jeu By Year centré sur une entreprise qui combine production, usines, matières premières, ressources humaines, financement et lancement de produits sur plusieurs pays. Le framework annuel reste commun; les décisions et calculs ENT1 v...
HR1 — architecture et logique game-specific
Positionnement HR1 est le jeu By Year orienté gestion des ressources humaines : staffing, rémunération, avantages, postings, contrats, CEO et segments d'employés. Static data Les datasets importés incluent ceo, employees, strategies, advantages, events, ...
MGT1 — architecture et logique game-specific (DEPRECATED)
Positionnement MGT1 modélise la gestion d'une équipe de développement : employés, temps de travail, features, segments, budget et lancement d'un jeu. Static data Les datasets comprennent employees, events, features, scenario, segments et act_perf_pond, p...
MK1 — architecture et logique game-specific
Positionnement MK1 est le moteur marketing By Year centré sur création de produit, choix de segment, prix, distribution, communication et lancement sur le marché. Static data Les datasets comprennent scenario, segments, product_specs, shops, price_specs, ...
MK2 — architecture et logique game-specific
Positionnement MK2 reprend le cœur marketing de MK1 mais ajoute notamment la logique pays/segments, relance, stock, loyauté et notoriété. Il doit donc être traité comme un moteur distinct plutôt qu'une simple skin MK1. Static data Les datasets comprennent pro...
Controllers, modèles et listeners runtime
Pattern général Le projet sépare les objets de données sérialisables des controllers runtime. Les classes de Assets/Src/Game/Data stockent les champs; les classes de Assets/Src/Game/Controllers ajoutent chargement, callbacks, caches, listeners RTT et opérati...
Machine d’état client — login, chargement et navigation
Architecture Le démarrage et la navigation principale utilisent des GameState. Chaque état effectue une opération asynchrone puis retourne Result.TransitionTo(...) lorsque la condition de transition est remplie. flowchart TD INIT[InitBackendState] --> AUTH[A...
Simulations, activités, équipes et utilisateurs
Hiérarchie métier commune flowchart TD USER[UserDetails] --> SIM[Simulation] SIM --> ACT[Activities] SIM --> ST[Students / Team stubs] ACT --> TEAM[Teams] TEAM --> MEMBER[TeamMember + Roles] ACT --> GS[ActDataGameSpec] TEAM --> DEC[Decisions / Modules] Simulat...
Notifications et présence
Notifications envoyées depuis Unity Le Game envoie les notifications au backend Web. NotificationManager.SaveNotification() lance la coroutine BackEndBase.SaveNotification(), qui effectue POST /saveNotification avec userUid, notificationType, isImportant...